与使用HTML + Javascript + Services应用程序相比，使用传统MVC框架有什么优势？

Question

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

客户看不到使用这些框架的价值。他们更喜欢使用传统的超文本标记语言，并通过JavaScript调用Web Services来获取所有数据。对他们来说，SOA非常重要，他们希望所有的应用程序都是面向SOA的。在当前的开发中，我们将一些数据返回到视图，用于主页的初始加载(使用ORM工具，在控制器中指定所有计算，并将模型返回到视图)，对页面的任何更新都是使用JavaScript调用Rest服务来执行的。客户抱怨使用控制器将数据返回到视图。他们希望所有数据都通过web服务返回，因此MVC框架对他们来说是无用的。为了“推销”MVC框架的使用，我应该对客户说些什么呢？

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

谢谢

Answer 1

JSON MVC，你可以利用一个面向服务的架构，并继续使用MVC作为后端，前端会遇到你的html、javascript来使用(前端控制器)并使用ASP.net连接到你的后端进行消息传递(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应用程序依赖于大量服务的情况下，后端代码可能无法获得它的支持。