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