我现在正在构建一个 Web 应用程序，而客户不确定是否使用 ASP.NET MVC 或任何其他 MVC 框架（Rails、Djando 或其他也适用）。
客户没有看到使用这些框架的价值。他们更喜欢使用传统的 HTML 并通过 JavaScript 调用 Web 服务来获取所有数据。对他们来说 SOA 非常重要，他们希望所有的应用程序都是面向 SOA 的。在当前的开发中，我们正在向视图返回一些数据，用于初始加载主页（使用 ORM 工具并在控制器中完成所有计算并将模型返回到视图），并执行对页面的任何更新使用 JavaScript 调用 Rest Services。客户抱怨使用控制器将数据返回到视图。他们希望所有数据都通过 Web 服务返回，因此 MVC 框架对他们来说毫无用处。我可以对客户说什么来“推销”MVC 框架的使用？
使用每种架构的优缺点是什么？
谢谢
ASP.net MVC，你可以利用面向服务的架构，后端继续使用MVC，前端会满足你的html，javascript来使用（前端控制器）并使用SOA连接你的后端后端的消息传递 (JSON) 可以使用 MVC 架构来管理您的服务
这一切都取决于......
当然，您可以在 JavaScript 中使用 MVC 模式。您还可以将 MVC 应用程序挂接到面向服务的体系结构中。
我认为问题归结为“您在哪里构建页面” - 前端或服务器端。
在浏览器中构建页面的好处是显而易见的。您可以更轻松地进行扩展，因为大量繁重的工作发生在客户端。您被迫创建松散耦合的服务，您可以通过许多有趣的方式组合这些服务。
缺点可能有点微妙。大多数搜索引擎不会执行 JavaScript，因此您的服务呈现的 HTML 很可能对它们不可见。随着浏览器数量的增加（智能手机、智能电视等），测试这种应用程序逻辑可能会变得不堪重负。实际上，您想要放入 JavaScript 的业务和应用程序逻辑的数量可能会受到限制——下载时间和执行时间可能会成为一个问题，并且需要开发团队的大量纪律。根据页面逻辑，您可能无法像在服务器上构建页面时那样缓存那么多。
服务器端页面构建的好处也相当明显：您可以利用完善的库和框架。您的页面可以缓存在浏览器或 CDN 上。通过在服务器上测试业务和/或应用程序逻辑，您可以确信它可以在所有设备上运行（尽管用户界面可能会损坏）。在服务器上构建它们时，以不同格式（例如 HTML 和 RSS 版本）公开服务器生成的页面可能更容易。
服务器端页面生成的缺点包括不容易分离不同的组件并重新使用它们，除非您从一开始就进行设计。在 Web 应用程序依赖大量服务的情况下，后端代码可能无法继续使用。