我是 ASP.Net MVC 的初学者。在阅读了许多教程并消化了它的概念之后，我还没有看到一种方法可以清楚地展示业务逻辑的去向。
我的应用程序将大量使用 jQuery AJAX 用法（它将调用 Controller 的 Actions 用于各种目的，例如依赖交互、验证）。我肯定会使用 ViewModel 概念，但我仍然不清楚业务逻辑应该放在哪里。我不想放入控制器或模型。我应该把它放在一个单独的服务层吗？
【问题讨论】：
标签： asp.net-mvc asp.net-mvc-3 business-logic-layer
您可以简单地将一些业务逻辑放在一个单独的 c# 类中并在控制器中引用它。这就是在网络表单时代隔离代码的方式。
【讨论】：
我见过的大多数简单示例都将简单的业务逻辑放在控制器中，但理想情况下您可能希望创建一个业务层。
使用 MVC3 分离业务逻辑的一个很好的例子可以在微软的项目 Silk 中看到，你可以下载 here。在此解决方案中，业务逻辑被分离到与 MVC 项目不同的项目中。
在这个项目中，您可以看到控制器逻辑只是处理视图和视图模型之间的通信（注意视图模型而不是业务层模型）。视图模型只包含将传递给视图的信息，因此如果视图上的字段更改，视图模型中的字段也会更改。该项目还进一步将视图模型分离为视图模型以将数据传递到视图中，并形成模型以将数据传回，但这是一个选择问题。
该项目使用事务脚本设计模式来实现其业务逻辑。控制器使用它自己的视图模型将信息传递给业务层，这些视图模型在命令模式设计中实现了一个接口。从业务层传回的信息是通过业务层自己的业务模型完成的。我强烈建议您查看这个项目，以更好地了解分离是如何实现的。
对于业务层的进一步阅读，我还建议您查看Wrox Enterprise .NET，其中有几章很好地讨论了构建业务层的选项，其中第一个是丝绸项目。
希望这会有所帮助。
【讨论】：
我认为您在一个单独的项目中几乎回答了您自己的问题。
不在控制器中，也绝对不在模型中。
编辑：请注意，控制器与 httpcontext 高度耦合，因此将逻辑层移动到不同的 dll 层将是一件非常聪明的事情。
【讨论】：
MVC 中的 M 是用于获取和处理您在应用程序中使用的信息的所有内容。因此，业务层是其中的一部分。
我将首先创建一个单独的类库并将我的所有逻辑放入其中。只要你的类相当小并且有clear responsibility，那么以后如果你需要一个单独的网络服务（另一个项目需要访问数据）就很容易重构。
我通常创建第三个类库并将所有定义（服务接口和域模型）放入其中。通过这样做，您将遵循separated interface pattern 并在以后更轻松地交换实现（并测试您的业务层）
【讨论】：