使用传统的MVC框架Vs使用HTML + Javascript + Services应用程序有什么好处？

Question

我现在正在构建一个Web应用程序，客户不确定是否使用ASP.NET MVC或任何其他MVC框架（Rails，Djando或其他也适用）。

客户并没有看到使用这些框架的价值。他们更喜欢使用传统的HTML并通过JavaScript调用Web服务来获取所有数据。对于他们来说SOA非常重要，他们希望所有应用程序都是面向SOA的。在当前的开发中，我们将一些数据返回到视图以初始加载主页（使用ORM工具并在控制器中执行所有计算并将模型返回到视图），并执行对页面的任何更新使用JavaScript调用Rest服务。客户抱怨使用控制器将数据返回到视图。他们希望通过Web服务返回所有数据，因此它们的MVC框架是无用的。我能告诉客户“出售”MVC框架的用途吗？

使用每种架构的优点和缺点是什么？

由于

Answer 1

ASP.net MVC，你可以利用面向服务的架构并继续使用MVC作为后端，前端将满足你的html，javascript使用（前端控制器）并使用SOA连接到你的后端的消息传递后端（JSON）可以有一个MVC架构来管理您的服务

Answer 2

一切都取决于......

您当然可以use the MVC pattern from within JavaScript。你也可以hook an MVC application into a service-oriented architecture。

我认为问题归结为“你在哪里构建页面” - 前端或服务器端。

在浏览器中构建页面的好处是显而易见的。您可以更轻松地扩展，因为客户端会发生很多繁重的工作。您被迫创建松散耦合的服务，您可以通过许多有趣的方式进行组合。

缺点可能有点微妙。大多数搜索引擎都不会执行JavaScript，因此您的服务呈现的HTML很可能对它们不可见。随着浏览器数量的增加（智能手机，智能电视等），测试这种应用逻辑会变得势不可挡。实际上，您希望在JavaScript中放置业务和应用程序逻辑的数量可能会受到限制 - 下载时间和执行时间可能会成为问题，并且需要开发团队的大量纪律。根据页面逻辑，您可能无法像在服务器上构建页面那样缓存。

服务器端页面构建的好处也很明显：您可以利用完善的库和框架。您的页面可以缓存在浏览器或CDN上。通过测试服务器上的业务和/或应用程序逻辑，您可以确信它可以在所有设备上运行（尽管用户界面可能会破坏）。在服务器上构建服务器生成的页面（例如HTML和RSS版本）时，可能更容易公开不同格式的服务器生成的页面。

服务器端页面生成的缺点包括不能轻易拆分不同的组件并重新使用它们，除非您从一开始就设计它。如果Web应用程序依赖于大量服务，则后端代码可能无法获得保留。