MVC中业务逻辑放在哪里？

Question

11

我是ASP.Net MVC的初学者，在阅读了很多教程并理解了其概念后，我还没有看到清晰展示业务逻辑放在何处的方法。

我的应用程序将大量使用jQuery AJAX(将调用控制器的操作来进行依赖交互、验证等各种目的)。我肯定会使用ViewModel概念，但我仍然不清楚业务逻辑应该驻留在哪里。我不想把它放在控制器或模型中，我应该将它放在单独的服务层中吗？

- sarsnake

2

为什么你不想把它放在一个模型里？ - Ferruccio

5个回答

7

MVC中的M指的是用于获取和处理应用程序中使用的信息的所有内容。因此，业务层也是其中的一部分。

我建议先创建一个独立的类库并将所有逻辑放入其中。只要您的类相对较小且具有清晰的责任（请参见单一职责原则），以后如果需要单独的Web服务（另一个项目需要访问数据），就很容易进行重构。

我通常会创建第三个类库，并将所有定义都放入其中（包括服务接口和领域模型）。这样做可以遵循分离接口模式，使得以后更换实现变得更加容易（还可以测试业务层）。

- jgauffin

3

理论上，业务逻辑位于3层架构的中间层。

- iamsohel

2

你可以将一些业务逻辑放在单独的C#类中，并在控制器中引用它。这是在Web表单时代隔离代码的方式。

- Jason

1

我看到的大多数简单示例将简单的业务逻辑放在控制器中，但理想情况下，您可能希望创建一个业务层。

使用MVC3分离业务逻辑的一个很好的例子可以在Microsoft的Silk项目中看到，您可以从这里下载。在这个解决方案中，业务逻辑被分离到与MVC项目不同的项目中。

在这个项目中，您可以看到控制器逻辑仅处理视图和视图模型之间的通信（注意是视图模型而不是业务层模型）。视图模型仅包含将传递给视图的信息，因此如果视图上的字段更改，则视图模型中的字段也会更改。该项目还进一步将视图模型分离为用于将数据传递到视图的视图模型和用于将数据传递回来的表单模型，但这是选择问题。

该项目使用事务脚本设计模式进行其业务逻辑。控制器使用自己的视图模型通过实现命令模式设计中的接口将信息传递给业务层。从业务层返回的信息是通过业务层自己的业务模型完成的。我强烈建议您查看此项目，以更好地了解如何实现分离。

如果您想进一步了解业务层方面的知识，我建议您阅读Wrox Enterprise .NET。该书的几章内容对于业务层结构的选项进行了深入讨论，其中第一种模式是项目 Silk 中使用的事务模式。

希望这能帮到您。

- Dangerous

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- gdoron is supporting Monica · Accepted Answer

我认为你在另一个项目中已经回答了自己的问题。
不要放在控制器里，也绝对不能放在模型中。

编辑：请注意，控制器与httpcontext高度耦合，因此将逻辑层移动到不同的dll层是非常明智的。