带有Web API的纯前端JavaScript与带有Ajax的MVC视图

这更多是关于人们近来对如何拆分Web应用程序的想法的讨论。

我习惯于使用其所有视图和控制器来创建MVC应用程序。通常，我将创建一个完整视图，并在一个完整页面请求中将其传递回浏览器，除非我不想立即填充特定区域，然后使用DOM页面加载事件来调用服务器来加载其他区域使用AJAX。

同样，当涉及部分页面刷新时，我将调用MVC操作方法，该方法将返回HTML片段，然后可以使用该HTML片段填充页面的某些部分。这将用于那些我不想减慢初始页面加载速度的区域，或者是更适合AJAX调用的区域。一个示例是表分页。如果您想转到下一页，我希望在AJAX调用获得该信息而不是使用整页刷新的情况下使用。但是AJAX调用仍然会返回HTML片段。

我的问题是。我对这个古老的想法是因为我来自.net背景，而不是纯粹的前端背景吗？

与我一起工作的聪明的前端开发人员，宁愿在MVC视图中什么也不做，而宁愿在前端做任何事情。一直到填充页面的Web API调用。因此，他宁愿返回一个标准对象并使用javascript创建页面的所有元素，而不是调用返回HTML的MVC操作方法。

前端开发人员的方式意味着我通常通过MVC模型验证（包括客户端验证）获得的任何好处都将消失。这也意味着我创建视图，使用强类型html模板等获得的任何好处都将消失。

我相信这意味着我需要为前端和后端验证编写相同的验证。javascript还需要有很多方法来创建DOM的所有不同部分。例如，当向表中添加新行时，我通常会使用MVC部分视图创建该行，然后将其作为AJAX调用的一部分返回，然后将其注入表中。通过使用纯前端方式，javascript将为api调用中的行引入一个对象（例如产品），然后从该对象创建一行。创建表行的每个单独的部分。

有问题的网站将在管理，表格，产品搜索等方面有很多不同的领域。我认为不需要以单一页面应用程序方式构建的网站。

大家对此有何想法？

我很想听听前端开发人员和后端开发人员的意见。

我还对每个新的Web应用程序都需要成为SPA持怀疑态度，但是我作为一名通才，以100％的价格出售了我，他在客户端方面的大量经验是，一种面向服务的体系结构会毫无用处无论是从服务器加载预构建的页面/视图，还是在页面加载后对数据进行大量动态处理，还是使用JavaScript几乎100％构建所有内容，都可以使用数据而不是HTML传输给客户端。

这比客户端开发人员更喜欢的原因与没有人希望在数据库中使用HTML的原因几乎相同。客户端开发人员要在使用HTML时求助于表时，应该做什么？与发出另一个服务器请求为您执行此操作相比，处理客户端上所有这些操作的性能成本微不足道。此外，HTML构建在JS-land中已广为人知。对于经验丰富的客户端开发人员而言，对数据进行排序并从中构建新的HTML表行是一件微不足道的工作。

另一个设备的后端体系结构到前端的体系结构有什么用，可能需要做一些异乎寻常的事情，例如100％画布或完全不同的HTML结构的实现小部件？为什么客户端开发人员必须加载Visual Studio或敲打后端开发人员的门才能进行严格的演示调整？

关于您担心丢失强类型模板验证的问题，请相信我，当我说如果您正在与一个有能力的客户端开发人员打交道，那么您将找不到.NET框架或Visual Studio工具，它更适合于关于格式正确，有效的HTML的详细信息，请参见他/她。

从全栈角度来看，我喜欢它，因为这意味着我永远不必为了某些业务或应用程序逻辑而垂头丧气。更不用说它从服务器上释放的每用户负载，而在许多情况下，实际上却可以改善具有现代计算机的现代浏览器中用户的负载体验。

我认为将后端架构与所有演示文稿完全隔离开来时，也更容易推断后端架构。您不再需要获取将数据混入某些HTML中的数据。您正在将其组合在一起，以创建一个与实现无关的数据结构，该结构在一般用途上比在另一侧要进行的操作更关注自身。IMO，由于数据现在是最终目标，而不是流程的倒数第二个步骤，因此趋向于提高处理方式的一致性，并且无关紧要的问题越少越好。

我会给我非常主观的2便士价值（以它的价值为准；）。对此没有正确或错误的答案，除了您的观点之外，还有许多现实世界的注意事项，例如：

• 您在房屋方面有相关经验吗？构建客户端驱动的应用程序与主要由服务器驱动的应用程序具有完全不同的技能集完全不同。
• 您希望它花多长时间？需要支持哪些浏览器？-您在客户端上执行的操作越多，您将面临的浏览器问题就越多；IE8很痛苦，JavaScript性能也很差，但是有很多企业在运行XP / IE设置。
• 您的用户将在哪些设备上查看站点？JavaScript的解析和运行在最新版本的Chrome上可能很快，但是在较旧的移动设备上却不是，尤其是其中没有大量带有业务逻辑的JavaScript
• 初始负载有多重要？服务器模板比客户端模板快

这个列表绝不是详尽无遗的，听起来像是对客户的猛烈抨击，这不是我的意图，我已经将网站重点放在前端。

对我而言，这实际上取决于用户体验和API可重用性。解决这些问题。

如果您要制作应用程序或提供API，那么使用.Net API项目很有意思，然后形成逻辑，检查和跨平台实现。在这种情况下，最好使用完整的客户端方法，API可以单独维护，仅提供与您的应用程序的接口。您可以修改逻辑并舒适地进行重构，而只需保持接口相同即可。您可以使用相同的后台代码轻松地为不同的媒体编写不同的应用程序。

对于纯前端解决方案，最强有力的论据（以我的观点）是用户体验。

（在考虑所有不利因素之后）纯JavaScript浏览器应用程序是否可以在传统网站上大大提高可用性和用户体验？

创建类似于本机应用程序的网站时；我认为答案显然是肯定的。但是，大多数站点并不是那么干净利落，因此要评估单个用户工作流程是否受益于高度动态的界面。

我对此采取相当务实的看法，这不是一个问题。JavaScript显然会与Server技术一起玩得很开心，您不必选择其中一个-每个站点都不是一个页面的Web应用程序-但是没有什么可以阻止您在各个页面上使用Knockout，骨干网等来在必要的地方进行改进。

我与前端繁重的应用程序存在着讨厌的关系。

一方面，我喜欢编写JavaScript，也喜欢将浏览器作为执行环境。

另一方面，两者都感觉就像是一级方程式赛车，引擎上有孔。确实可以归结为：您可以防止C＃和JavaScript之间的业务逻辑重复吗？如果是这样，请使用任何方法生成您认为值得的视图。如果您要用两种语言复制业务逻辑，则可能有一个前端开发人员只想编写JavaScript，却不太清楚。

至于技术差异：

渲染部分并将其交付给客户端：

• 易于实现
• 防止后端业务逻辑在前端重复
• 可能导致浏览器的HTTP有效负载更大。在具有高带宽连接的桌面上，这不是一件坏事。当您坐在高峰时间的火车上以60mph的速度降速时，在一部虚弱的手机上这非常糟糕，而另外1,000部手机同时从一个蜂窝塔断开连接，并试图重新连接到下一个蜂窝塔。

传递JSON并呈现客户端模板：

• 可以产生比HTML小的HTTP有效负载，这可以使应用程序在不可靠或缓慢的网络连接上显得响应更快
• 许多JavaScript模板语言功能齐全，这意味着我们不需要后端就可以生成一些HTML

有时，我认为较新的JavaScript框架正在把婴儿扔掉，-我希望我不会成为脾气暴躁的curmudgeon程序员...

在上一个应用程序中，我结合了REST api和JavaScript前端。

我所做的是：

• 我为CRUD操作创建了REST API。
• 我创建了一个Javascript应用程序，该应用程序可加载预定义的HTML模板，并填充从REST API返回的数据。

基本上，JS前端与REST API进行CRUD操作通信，并使用返回的数据或创建的数据填充HTML，或者删除已删除的数据或更新更改的数据。

因此，我们有了纯HTML，我们在客户端完成了处理，由于不必加载所有HTML，带宽使用量减少了，并且可以为用户提供真正的Web 2.0体验。

我不会在前端进行业务验证以确保安全和代码重复，因为任何人都可以在将数据发送到服务器之前更改数据，而我们必须再次验证服务器上的数据。因此，这很容易被黑客入侵。所有验证均在后端完成。仅对输入类型进行客户端验证。

优点：

• 由于不是JS生成的事实，因此可以对HTML进行更改；
• 通过使用ajax和JSON降低带宽消耗；
• 由于在客户端填充了HTML，因此降低了服务器处理的消耗；
• 通过使用JS更改屏幕来改善用户体验，允许使用效果并提高渲染速度。
• 通过使用REST，可以更好地使用HTTP协议。

缺点：

• 2个申请要维护；
• 取决于客户端处理，这可能由于硬件较差而变差。

希望这可以帮助。

问候，

关于validationWeb Api中的方面-可以执行“模型验证”并以400错误的请求http响应进行响应。

请参阅/programming/11686690/handle-modelstate-validation-in-asp-net-web-api/25050285#25050285