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

Question

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

Answer 1

它可能但不太可能； 有哪些驱动程序向您建议该架构？ 只是有所不同还是最能解决某些特定方面？

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

从理论上讲，您仍然可以拥有一个适当的分层解决方案（Business Logic（BL）脚本与针对UI的脚本），但实际上它会很混乱。 并且您将失去将其物理上划分为不同层的能力。 这可能会在系统寿命中的任何地方“咬住”您。

“企业”级别的系统很少这么小，我讨厌考虑您必须通过有线方式发送多少逻辑来支持给定的操作/流程。

将所有BL放入脚本语言后，您便会与该平台建立联系，并且平台会随着时间的推移而变化。 关于脚本的坏处是，尽管它们在一定程度上是稳定的，但我建议它们比基于Java或.Net的基于服务器的平台更容易受到更改的影响。 在企业场景中，服务器将具有非常严格的变更控制和为其映射的升级路径-因为浏览器更易于进行定期变更。

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

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

安全性：将核心BL暴露在暴露得多的客户端上非常危险。

编辑：

可以播种Web Apps的原因有很多-没什么理由足以将您所有的BL放在客户端的JavaScript中。 为性能而构建应用程序是一个整体的工作领域-我建议您在完全注销n层Web应用程序之前更加熟悉为性能设计和实施：)

关于将各层分开：有不同的方法，但可以归结为抽象-更准确地说，是要牢记好的设计原则。 如果您还没有听说过SOLID ，那将是一个不错的起点。 在实现方面，开始阅读Dependency Inversion （FYI-自我提升，这些文章属于我，并且是.Net的，但您也应该不会遇到基于Java的问题）。