所以最近我进行了一些采访，而且四个问题不断出现的问题是“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中需要应用以下基本功能的事实可以支持哪些差异而不是意见？
业务逻辑在哪里？
需要在何处应用验证？
验证需要在哪里确认？
你有什么其他问题可以借给这个？
答案 0 :(得分：3)
根据我的经验，这是我的意见，目前我正在开发一个angularjs / servicestack应用程序，所以我们走了：
对于这些问题，没有正确的答案，但我认为最常见的更胜一筹：）
业务逻辑在哪里？ 这基本上可以使用MVC / php / Rails o任何其他服务器端编程语言，因为我正在使用服务堆栈我将所有业务操作分开，我在MVC中称为业务服务它可能是相同的，记得控制器无论你使用的是哪个框架都是编排视图和模型之间通信的框架，我不明白为什么你需要将任何类型的逻辑放入控制器。
关于Javascript / Server框架的关系我把JS MVC视为调用我的REST服务的客户端（或者带有js库/ Web API的MVC应用程序等），js客户端只发送/获取信息该服务，您可以在那里执行小型客户端操作，但不能执行与您的系统模型严格关联的操作，Js框架的MVC更像是一种将关注点分离到引导TDD和DI的方式（至少是AngularJS）
需要在何处应用验证？ 在任何地方，客户端验证都很合适，因为它们会向用户提供即时反馈，但您必须仔细检查服务器中的所有输入。
对我来说，所有的架构在组织层和层的方式上都可以保持非常相似，最后它改变的是你如何向客户提供信息，如果它是不喜欢回发客户端框架或只是简单的视图。
这是我的两分钱， 我希望这是有道理的。
答案 1 :(得分：0)
业务逻辑客户端只是最终用户的便利（也可能是性能）。
在您点击服务器之前，不需要应用业务逻辑验证。
一旦你点击了服务，你就“必须”确认/应用业务逻辑，因为你无法真正信任你无法控制的环境。
如果我们想象我们是Gmail一秒钟，我们可以运行几个场景。
如果业务逻辑与任何类型的验证无关，比如弹出我知道我可以发送电子邮件的人员列表，那么它属于客户端。
如果业务逻辑确保某人没有将某种恶意html泄露到他们的电子邮件中，那么验证需要在服务器端进行。
恶意我只能模仿ajax对gmail的调用假装我在html中编写了一封包含恶意代码的电子邮件。但智能谷歌转身并检查通话内容，以确保我没有欺骗一些无效信息。