JavaScript MVC 与 ASP.NET MVC（模式差异）

Posted 2023-02-24

【中文标题】JavaScript MVC 与 ASP.NET MVC（模式差异）

【英文标题】：JavaScript MVC vs ASP.NET MVC (Pattern Differences)

【发布时间】：2013-08-15 07:02:12

【问题描述】：

问题 - （背景故事）

所以最近我参加了几次采访，四个人不断提出的问题是“X 在 MVC 应用程序中的位置是什么？”

问题是我面试的公司每次都不一样。两个主要是 ASP.NET MVC / Microsoft 商店，另外两个使用 Ext.js、Ember.js、Angular.js 或其他一些 javascript MVC 框架。

我的答案 -

业务逻辑在哪里？

ASP.NET MVC

在服务器上的单独层中

JavaScript MVC

理论上，在控制器上或周围...... 但它并不安全......

验证在哪里？

ASP.NET MVC

在模型中，视图使用它来简单地提醒问题，控制器在尝试提交之前验证模型状态。

JavaScript MVC

嗯，在模型中，但是...在视图中，但是控制器将其提供给...

什么是对的？

我的问题是，与 ASP.NET MVC 相比，以下基本功能需要在 JavaScript MVC 中应用的地方有哪些事实而非意见可以支持的差异 -

类别 -

业务逻辑在哪里？

需要在哪里应用验证？

验证需要在哪里确认？

你还有什么问题要问这个？

【问题讨论】：

我想无耻地重定向你there，因为我相信它是直接相关的。您可以从中提取的简短答案是，没有人可以声称能够以通用的方式回答您的问题，也不知道您的应用程序做了什么。我认为任何面临这个问题的人都应该深吸一口气，花几分钟忘记网络的复杂性，并在更高的层次上思考这个问题。 让架构由您的需求驱动。

【参考方案1】：

这是我根据经验得出的看法，目前我正在开发一个 angularjs/servicestack 应用程序，所以我们开始吧：

这些问题没有正确的答案，但我想最好的答案是常识更胜一筹：)

业务逻辑在哪里？ 这基本上可以使用 MVC/php/Rails 或任何其他服务器端编程语言来应用，因为我使用的是服务堆栈，所以我已经将所有业务操作分离为我在 MVC 中称为业务服务的内容，它可能是相同的，请记住无论您使用什么框架，控制器都是协调视图和模型之间通信的框架，我不明白为什么您需要将任何类型的逻辑放入控制器中。

关于 Javascript/Server 框架的关系，我将 JS MVC 视为调用我的 REST 服务（或带有 js 库/Web API 等的 MVC 应用程序）的客户端，js 客户端只是发送/获取来自服务，您可以在那里执行小型客户端操作，但不能执行严格绑定到您的系统模型的操作，Js 框架的 MVC 更多的是一种分离关注点以引导 TDD 和 DI（至少是 AngularJS）的方式

需要在哪里应用验证？ 在任何地方，客户端验证都非常适合，因为它们可以向用户提供即时反馈，但您还必须仔细检查服务器中的所有输入。

对我来说，所有架构在如何组织层和层方面都可能保持非常相似，最后它改变的是你将如何向客户呈现信息，如果它是不喜欢回发客户端框架或只是简单的视图。

这里只有我的两分钱， 我希望这是有道理的。

【参考方案2】：

业务逻辑客户端只是为最终用户提供便利（可能还有性能）。

在您访问服务器之前，“不需要”应用业务逻辑验证。

点击发球后，您“必须”确认/应用业务逻辑，因为您永远无法真正信任您无法控制的环境。

如果我们暂时想象一下自己是 Gmail，我们可以运行几个场景。

如果业务逻辑与任何类型的验证无关，例如弹出一个我知道我可以向其发送电子邮件的人的列表，那么它属于客户端。

如果业务逻辑确保某人没有将某种恶意 html 偷偷放入他们的电子邮件中，则验证需要在服务器端进行。

恶意的我可以模拟对 gmail 的 ajax 调用，假装我在 html 中编写了包含恶意代码的电子邮件。但 Smart Google 转身检查通话内容，以确保我没有欺骗一些无效信息。