我想知道是否可以在不使用标准 MVC 结构和应用程序服务器的情况下开发企业级 Web 应用程序，方法是将业务/流逻辑和会话数据传输到客户端大小的 Javascript 并让它说话直接到 REST 数据服务...也许我们可以使用授权/身份验证层和位于数据服务之上的第二个验证层。所有这些服务都在标准的 HTTP 方法上运行，支持可配置的日志记录和监控，内容或查询参数都包含在 HTTP 请求/响应正文中。静态 HTML 和 Javascript 提供给浏览器，其余由 Javascript 函数执行，与基于 HTTP 的授权/身份验证、验证和数据服务通信。您认为这种架构能满足企业级 Web 应用需求吗？
【问题讨论】：
有可能，但不太可能；向您推荐这种架构的驱动因素是什么？只是为了与众不同还是有一些特定方面可以最好地解决？
通过承载业务/流程逻辑 和会话数据到客户端 Javascript 并使其与 REST 对话 直接数据服务
理论上您仍然可以拥有一个适当分层的解决方案（业务逻辑 (BL) 脚本与以 UI 为中心的脚本），但实际上它会很混乱，而且您会失败将其物理分离为不同层的能力。这可能会在系统生命周期中的任何地方“咬”你。
“企业”级系统很少很小，我不想考虑您必须通过网络发送多少逻辑来支持给定的操作/流程。
将所有 BL 放入脚本语言会将您与该平台联系起来，并且平台会随着时间而变化。脚本的坏处在于，虽然它们在一定程度上是稳定的，但我建议它们比 Java 或 .Net 等基于服务器的平台更容易受到变化的影响。在企业场景中，服务器将有非常严格的变更控制和为它们规划的升级路径——而浏览器则更容易接受定期变更。
存在兼容性问题 - 除非您被绑定到特定浏览器（到版本级别），否则要保证一致的行为将变得更加困难，并且可能需要更多的开发工作。假设您成功交付了解决方案；当企业想要利用移动计算（例如 iPad）时，您会怎么做？您唯一的选择将是浏览器——您将无法利用该平台的任何原生优势。 “网络和浏览器”似乎会永远存在——但我猜想这就是 MainFrame 人当时所说的。以服务器为中心的解决方案将以更少的费用为您提供更多的生活。
人员配备将是一个问题 - 您需要非常强大的 JavaScript 和服务器端开发人员。
安全性：将核心 BL 放在暴露得多的客户端听起来非常危险。
编辑：
Web 应用程序可以被播种的原因有很多——其中没有多少理由足以将您的 BL 放在客户端的 JavaScript 中全部。为性能而构建应用程序本身就是一个完整的领域 - 我建议您在完全取消 n 层 Web 应用程序之前更熟悉为性能而构建和实现 :)
关于保持层分离：有不同的方法可以做到这一点，但归结为抽象 - 更准确地说是牢记良好的设计原则；如果您还没有听说过SOLID，那将是一个不错的起点。在实现方面，开始阅读Dependency Inversion（仅供参考 - 自我推销，这些文章是我的，并且专注于 .Net，但你也应该没有问题追踪基于 Java 的文章）。
【讨论】：