Architecture 企业Web应用程序体系结构问题

我想知道，如果不使用标准的MVC结构和应用服务器，通过将业务/流逻辑和会话数据传输到客户端大小的Javascript并使其直接与REST数据服务通信，是否可以开发企业级web应用程序……也许我们可以使用授权/身份验证层和位于数据服务顶部的第二个验证层。所有这些服务都在标准HTTP方法上运行，支持可配置的日志记录和监视，并且内容或查询参数都包含在HTTP请求/响应主体中。静态HTML和Javascript被提供给浏览器，其余的由Javascript函数与基于HTTP的授权/身份验证、验证和数据服务进行通信。您认为这种体系结构能够满足企业级web应用程序的需求吗？

这是可能的，但不太可能；向您推荐此体系结构的驱动因素是什么？这仅仅是为了与众不同，还是有一些特定的方面，这是最好的解决方案

通过携带业务/流逻辑 并将会话数据发送到客户端 Javascript并使其与REST对话 直接数据服务

在理论中您仍然能够拥有一个适当分层的解决方案（业务逻辑（BL）脚本与以UI为中心的脚本），但实际上，这会很混乱；这样你就失去了物理上把它分成不同层次的能力。这可能会在系统生命中的任何地方“咬”你

“企业级”系统很少是小型的，我讨厌去想，为了支持一个给定的操作/过程，你必须通过网络发送多少逻辑

将所有BL放到脚本语言中会将您绑定到该平台，并且平台会随着时间的推移而变化。脚本的坏处在于，虽然它们在某种程度上是稳定的，但我认为它们比基于服务器的平台（如Java或.Net）更容易受到变化的影响。在企业场景中，服务器将有非常严格的更改控制和升级路径，因为浏览器更容易接受常规更改

还有一个兼容性问题——除非您绑定到特定的浏览器（版本级别），否则保证一致性行为将变得更加困难，并且可能需要更多的开发工作。假设您成功交付了解决方案；当企业想要利用移动计算（比如iPad）时，你会怎么做？您唯一的选择将是浏览器-您将无法利用该平台的任何固有优势。“网络和浏览器”似乎将永远存在——但我猜当时大型机的人是这么说的。以服务器为中心的解决方案将使您以更少的费用获得更多的生命

人员配置将是一个问题——您需要非常强大的JavaScript和服务器端开发人员

安全性：让你的核心BL暴露在客户身上听起来非常危险

编辑：

Web应用程序之所以能够被sow使用，有很多原因，但没有足够的理由将所有BL都放在客户端的JavaScript中。为性能构建应用程序本身就是一个完整的努力领域——我建议您在完全注销n层web应用程序之前，更熟悉为性能构建和实现：）

---

关于保持层次分离：有不同的方法可以做到这一点，但归根结底是抽象——更正确的是，要记住良好的设计原则；如果你还没有听说过，那将是一个很好的开始。在实现方面，请开始阅读（仅供参考-自我推广，这些文章以.Net为重点，但您也可以轻松找到基于Java的文章）。

非常感谢您给出了如此好的答案，Adrian。尝试不同的路径无疑是驱动因素之一，但最强大的驱动因素是我在各种Java框架上开发的web应用程序的低响应性，即在OC4J和Tomcat上运行的Spring MVC、Struts 2和Oracle ADF。这可能是我在Java框架和应用程序服务器上采用的糟糕做法，但不知何故，我在开发基于PHP和Ajax的脚本繁重的web解决方案时获得了更高的响应能力和灵活性。即使我使用传统的n层方法并在物理上分离各层，从逻辑上讲，各层仍然相互关联，一方在不了解另一方的规范的情况下无法运行，而另一方的每一方都必须得到关于任何其他方变更的更新。Javascript不是实现BL的完美媒介，我完全同意你的观点…我不知道是否有可能通过加密发送过来的Javascript代码来隐藏逻辑，但这并没有改变JS开发/维护相当混乱的事实……这让我想到将BL层实现为一个独立的服务层，如BPEL，但它是一个可以在标准HTTP方法上运行的更轻/最小版本。这种解决方案可以尝试解决JS和浏览器依赖性问题，并且在将应用程序移植到另一个平台（如桌面和移动平台）时仍然可以正常运行。当我使用WSO2数据服务服务器和Axis2 wsdl2java工具生成的客户端库作为数据访问层时，我受到了启发，我可以说，它比ORM对我来说要舒服得多……但我希望我能在没有SOAP/WSDL膨胀的情况下实现同样的功能，使用一种基于HTTP的、类似REST的结构，支持XML和JSON，用于数据访问和BL。再次感谢您的回答Adrian……我想进一步了解您的想法。