使用具有3层架构的MVC模式

Question

我在我的应用程序中使用ASP.NET MVC。我将我的应用程序划分为三层架构。 1）数据访问层（使用实体框架），2）应用程序/业务层，3）表示层（ASP.NET MVC）。

因为我在我的表示层使用MVC框架，所以我对业务逻辑感到困惑。我需要知道在哪里将业务逻辑放在MVC模式中。换句话说，我们可以说我需要在哪里调用我的中间层。从模型或控制器？

如果我从Controller调用我的业务逻辑，那么模型似乎没用。其他明智的是，如果我从模型中调用业务逻辑，那么它似乎是对系统的不必要的出价，因为业务对象映射模型然后模型传递给Controller。模型正是DTO正在做的事情。

任何帮助将不胜感激

Answer 1

ASP.NET MVC层或层既不包含业务逻辑也不包含业务模型。 M中的MVC代表UI模型，而不是应用程序核心的模型，MVC（以及其他MV*模式）通常是用于分离UI关注点的模式。您应该从控制器发送消息（调用）您的业务层（BL），聚合数据，创建或将结果映射到UI模型并将其传递给视图。您的UI模型应该不了解BL模型 - 这种区别使得应用程序的松散耦合层。

  

换句话说，我们可以说我需要在哪里调用我的中间层。   从模型或控制器？

绝对来自控制器。您将依赖项注入其中并从Action方法中调用它们。 ASP.NET MVC为控制器提供了许多注入依赖的机制，并与NInject，StructureMap和其他一些IoC容器很好地集成。

MVC中组件之间的依赖关系如下所示

图片来源于马丁的福勒关于GUI Architecture的文章，顺便说一下，关于MVC和MVP的阅读非常好。

此外，Pluralsight还有一套关于软件实践的视频，其中涵盖了设计模式。我从他们对MVVM和MVP的定义中学到了很多东西。

阅读这些材料不仅可以增加您对模式本身的理解，还可以增强您对应用程序环境的适应性以及与之交互的理解。

Answer 2

这是您必须根据自己的要求做出的纯粹设计/架构决策。

如果要扩展应用程序以支持其他服务/应用程序，建议不要在Controller / Model中编写任何业务逻辑。您可以在业务/应用程序层编写它。这将有助于您将来扩展您的架构。假设您想为移动应用程序创建restful服务，您可以将服务编写为包装器以重用现有业务/应用程序层。

另外只看看Domain Driven Design，Eric Evans的书值得一​​读。

http://dddsample.sourceforge.net/architecture.html