业务逻辑应该放在控制器/模型/视图项目中的什么位置答案

【问题标题】：Where should business logic be placed in a controller/model/view project业务逻辑应该放在控制器/模型/视图项目中的什么位置
【发布时间】：2014-01-24 04:56:07
【问题描述】：

我想知道创建复杂视图和模型的最佳做法是什么。

我一直在阅读，您应该在模型中处理业务逻辑，并且只使用控制器来处理请求和查看结果json、string 等。这是正确的吗？

我看到另一篇文章说业务逻辑应该在控制器中，而域逻辑在模型中。

此外，使用构造函数是最佳实践吗，或者这会导致诸如必须为其扩展绑定器之类的问题。

任何建议以及对模型视图和控制器的复杂设计实现的参考都将不胜感激。

【问题讨论】：

标签： c# .net asp.net-mvc oop asp.net-mvc-5

【解决方案1】：

有很多方法可以做到这一点，我喜欢把所有的层分离成单独的项目，做成MVVM的方式

总线逻辑，最好放在服务/域层
控制器用于获取/解析/发送请求/响应以查看
模型，即您的视图模型（不是您的业务模型），可能具有与您的模型相同或更多/更少的信息。

Orchard 是 mvc/piranha/nopcommerce 的一个很好的例子。

一些老的采用者把所有的业务逻辑放在模型中，还有一些把它们放在控制器中，我认为这不干净。

【讨论】：

我认为这很好地解释了这一点。感谢您的回复。
感谢来源参考顺便说一句。这正是我想要的。

【解决方案2】：

理想情况下，业务逻辑将单独放置在一个单独的项目中，不知道（无参考）网络项目或数据访问（也是单独的）项目。

【讨论】：

没有提到我们也在使用实体框架。我只是想知道这一点。就像使用构造函数和默认构造函数以及继承我的模型一样，对于我的情况来说是一个好主意，或者是一个不好的做法。似乎是处理这个特定视图部分的最佳方式。我想在坏习惯变成习惯之前把它们改掉。我刚在我们公司转行，所以正在学习它。
在大型项目中你至少应该有：1.数据库项目（表，视图等），2.业务层项目（你的Entity框架实体，+业务逻辑），3.Web项目（ MVC)。由于您使用的是 EF，因此您不需要单独的数据访问项目 (IMO)...
我有点不同意。即使您使用的是 EF，您仍然应该为您的域层使用类库。您可能现在只有一个项目需要与您的实体合作，但是一旦您需要第二个项目才能与它们进行交互，您就会好几天都自责。跨度>

【解决方案3】：

我的观点是所有业务逻辑都应该由另一个应用层来处理

Microsoft 有自己的 mvvm 定义，一旦我们在他们的平台上进行开发，它就会很有用。

查看：http://msdn.microsoft.com/en-us/library/ff798384.aspx

我一直在使用CSLA + MVVM + MEF，它证明自己非常有效。

【讨论】：

【解决方案4】：

关于 MVC（不是 MVVM）

出于几个原因，我更喜欢将领域逻辑放入模型中。

模型中应该没有 UI 代码，并且应该更容易测试。只要有可能，我喜欢在编写任何 UI 代码之前拥有一个完整工作的模型。控制器可以相信模型正在做正确的事情，并且只处理 UI 问题和重定向内容。
如果将域逻辑放在一个控制器中，那么在不同的应用程序甚至控制器之间共享就不是那么容易了！

【讨论】：