1

问题 - （背景故事）

所以最近我参加了几次采访，四个人不断提出的问题是“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 中应用的地方是事实支持的差异，而不是意见支持的差异 -

分类 -

业务逻辑在哪里？

需要在哪里进行验证？

验证需要在哪里确认？

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

4

2 回答 2

3

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

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

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

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

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

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

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

于 2013-08-14T00:10:23.900 回答
0

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

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

一旦你点击了服务，你“必须”确认/应用业务逻辑，因为你永远无法真正信任你无法控制的环境。

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

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

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

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

于 2013-08-13T16:02:40.253 回答