企业Web应用程序架构问题

Question

我想知道是否可以通过将业务/流逻辑和会话数据传输到客户端大小而不使用标准MVC结构和应用程序服务器来开发企业级Web应用程序Javascript并使其直接与REST数据服务交谈......也许我们可以利用位于数据服务之上的授权/验证层和第二个验证层。所有这些服务都使用标准HTTP方法进行操作，支持可配置的日志记录监视，并且内容或查询参数都包含在HTTP请求/响应正文中。向浏览器提供静态HTML和Javascript，其余部分通过与基于HTTP的授权/验证，验证和数据服务通话的Javascript函数执行。您认为这种架构可以满足企业级Web应用程序的需求吗？

Answer 1

它可能但不太可能;为你提供这种架构的驱动因素是什么？它只是为了不同，还是有一些具体的方面，这最好的地址？

所搭载的业务/流逻辑 和会话数据到客户端 Javascript和使它跟REST直接

数据服务在理论你仍然能有一个适当的分层解决方案（业务逻辑（BL）脚本vs用户界面焦点脚本），但实际上它会是混乱的;而且你会失去把它分成不同层次的能力。这可能会在系统生命周期的任何地方“咬”你。

“企业”等级的系统很少，我讨厌考虑你需要通过网络发送多少逻辑来支持给定的动作/过程。

把所有的BL都变成一种脚本语言将你与该平台联系起来，而且平台会改变加班。脚本的坏处在于，虽然它们在一定程度上稳定，但我认为它们比基于服务器的平台（如Java或.Net）更容易受到变化影响。在企业场景中，服务器将具有非常紧凑的变更控制和升级路径 - 因为浏览器对定期更改更加开放。

存在兼容性问题 - 除非你绑定到特定的浏览器（到版本级别），否则保证一致的行为将变得更加困难，并且可能需要更多的开发工作。假设您成功交付解决方案;当企业想要利用移动计算 - 例如iPad时，你会做什么？你唯一的选择就是成为浏览器 - 你将无法利用平台的任何本地优势。 “网络和浏览器”看起来可能会永远存在 - 但后来我猜测MainFrame当时所说的是什么。以服务器为中心的解决方案将为您节省更多的生命。

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

安全性：让您的核心BL出现在客户端，暴露得更多时听起来非常危险。

编辑：

Web应用程序可以播种的原因有很多 - 这不是很多都是足够的理由把所有您的BL在JavaScript在客户端上。构建性能应用程序本身就是一个努力的全部领域 - 我建议您在完成注销n-tier Web应用程序之前更熟悉架构和性能实现:)

关于保持图层分离：有不同的方式来做这件事，但它归结为抽象 - 更正确地记住保持良好的设计原则;如果你还没有听说过SOLID这将是一个很好的开始。在实施方面开始阅读Dependency Inversion（仅供参考 - 自我推广，这篇文章是我的重点，但你也应该没有问题跟踪基于Java的文章）。