企业Web应用程序架构问题

Question

我想知道是否有可能在不使用标准MVC结构和应用服务器的情况下开发企业级web应用程序，通过将业务/流程逻辑和会话数据携带到客户端大小的Javascript，并使其与REST数据服务directly...maybe对话，我们可以利用位于数据服务之上的授权/身份验证层和第二验证层。所有这些服务都运行在标准的HTTP方法上，支持可配置的日志记录和监控，并且内容或查询参数都包含在HTTP请求/响应主体中。静态HTML和Javascript被提供给浏览器，其余的由Javascript函数执行，与基于HTTP的授权/身份验证、验证，然后是数据服务对话。您认为这种架构能够满足企业级web应用程序的需求吗？

Answer 1

这是可能的，但不太可能；向您建议此体系结构的驱动因素是什么？它只是为了不同，还是有一些特定的方面，这是最好的解决？

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

在理论中，您仍然能够拥有一个适当分层的解决方案(业务逻辑(BL)脚本与以UI为中心的脚本)，但实际上，它将是混乱的，并且您将失去将其物理地划分到不同层的能力。这可能会在系统生命中的任何地方“咬”你。

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

把所有的BL放到一个脚本语言中，将你与该平台联系在一起，并且平台会随着时间的推移而变化。脚本的缺点是，虽然它们在一定程度上是稳定的，但我建议它们比基于服务器的平台(如Java或.Net )更容易发生变化。在企业场景中，服务器将具有非常严格的更改控制和升级路径-而浏览器对定期更改的开放程度更高。

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

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

安全性:将核心BL放在客户端，在那里它更容易暴露，这听起来非常危险。

编辑：

Web应用程序可以基于许多原因进行播种--其中没有多少原因足以将您所有的BL放在客户端的JavaScript中。构建性能应用程序本身就是一个完整的努力领域-我建议您在完全放弃n层web应用程序之前，更熟悉性能的架构和实现:)

关于保持层分离:有不同的方法可以做到这一点，但归根结底是抽象-更准确地说，是将良好的设计原则牢记于心；如果你没有听说过SOLID，那将是一个很好的起点。在实现方面，开始阅读Dependency Inversion上的(仅供参考-自我推广，这篇文章是我写的，并且是以.Net为重点的，但是你也应该可以很容易地找到基于Java的文章)。