11

我是 ASP.Net MVC 的初学者。在阅读了许多教程并消化了它的概念之后，我还没有看到一种方法可以清楚地展示业务逻辑的去向。

我的应用程序将大量使用 jQuery AJAX 用法（它将调用 Controller 的 Actions 用于各种目的，例如依赖交互、验证）。我肯定会使用 ViewModel 概念，但我仍然不清楚业务逻辑应该放在哪里。我不想放入控制器或模型。我应该把它放在一个单独的服务层吗？

4

5 回答 5

12

我认为您在一个单独的项目中几乎回答了您自己的问题。
不在控制器中，也绝对不在模型中。

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

于 2011-11-11T10:59:47.143 回答
7

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

我将首先创建一个单独的类库并将我的所有逻辑放入其中。只要你的类相当小并且有明确的责任，如果你需要一个单独的 web 服务（另一个项目需要访问数据），那么以后重构是很容易的。

我通常创建第三个类库并将所有定义（服务接口和域模型）放入其中。通过这样做，您将遵循分离的接口模式，并且以后更容易交换实现（并测试您的业务层）

于 2011-11-11T11:14:51.260 回答
3

理论上，业务逻辑涉及 3 层架构的中间层。在此处输入图像描述

于 2017-07-06T12:35:32.353 回答
2

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

于 2011-11-10T23:37:09.573 回答
1

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

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

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

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

对于业务层的进一步阅读，我还建议您查看Wrox Enterprise .NET，其中一些章节很好地讨论了构建业务层的选项，其中第一个是项目 Silk 中使用的事务模式.

希望这可以帮助。

于 2011-11-10T23:59:12.100 回答