我在我的应用程序中使用 ASP.NET MVC。我已将我的应用程序分为三层架构。1）数据访问层（使用实体框架），2）应用程序/业务层，3）表示层（ASP.NET MVC）。
因为我在表示层上使用 MVC 框架，所以我对业务逻辑感到困惑。我需要知道在 MVC 模式中我的业务逻辑应该放在哪里。换句话说，我们可以说我需要从哪里调用我的中间层。来自模型还是来自控制器？
如果我从 Controller 调用我的业务逻辑，那么模型似乎没用。否则，如果我从模型中调用业务逻辑，那么在系统上似乎是不必要的，因为业务对象与模型进行映射，然后将模型传递给控制器。模型正是 DTO 正在做的事情。
任何帮助将不胜感激
ASP.NET MVC层或层既不包含业务逻辑也不包含业务模型。MinMVC代表 UI 模型，而不是应用程序核心的模型，并且MVC（以及其他MV*模式）通常是用于分离 UI 关注点的模式。您应该从控制器发送消息（调用）您的业务层 (BL)、聚合数据、创建或将结果映射到 UI 模型并将其传递给视图。您的 UI 模型应该对 BL 模型一无所知 - 这种区别使您的应用程序的层松散耦合。
换句话说，我们可以说我需要从哪里调用我的中间层。来自模型还是来自控制器？
绝对来自控制器。您将依赖项注入它并从您的 Action 方法中调用它们。ASP.NET MVC 为控制器提供了许多注入依赖项的机制，并与 NInject、StructureMap 和一些其他 IoC 容器很好地集成。
MVC 中组件之间的依赖关系如下所示
图片取自 Martin 的 Fowler 关于GUI 架构的文章，顺便说一下，关于 MVC 和 MVP 的阅读非常好。
此外，Pluralsight还提供了一组关于软件实践的视频，其中涵盖了设计模式。我从他们对 MVVM 和 MVP 的定义中学到了很多东西。
阅读这些材料不仅可以增加您对模式本身的理解，还可以了解它们如何适应应用程序环境并与之交互。
这纯粹是您必须根据您的要求做出的设计/架构决定。
如果您想扩展您的应用程序以支持其他服务/应用程序，建议不要在 Controller/Model 中编写任何业务逻辑。您可以在业务/应用程序层中编写它。这将帮助您在未来扩展您的架构。假设您想为您的移动应用程序创建安静的服务，您可以将服务编写为包装器以重用现有的业务/应用程序层。
也只是看看领域驱动设计，埃里克埃文斯的书值得一读。