我将通过承认我对 MVC 非常陌生来开始这个问题。设计模式在较高层次上对我来说很有意义，但现在我正在探索 ASP.NET MVC，一些架构部分正在挑战我的先入为主的观念。学习是好事。
我最近一直在使用Oxite作为一种学习工具，由创建 ASP.NET MVC的公司的人员编写，因此，它是一个表面上的 ASP.NET MVC 参考应用程序。
但今天我看到Rob Conery写的一篇关于 Oxite 的博文，上面写着：
Oxite 团队决定做的一件事是将控制器和视图分离到另一个项目中，因为我只能假设业务逻辑与视图逻辑的分离。这可能会导致一些混乱，因为控制器旨在处理应用程序流 - 不一定是业务逻辑。
这让我陷入了困境。这种分离是 MVC 的一个原则，因此是 Oxite 开发人员的错误，还是 Rob 的观点？如果业务逻辑属于模型，为什么 Oxite 团队将其放在控制器中？如果不在控制器中，我如何执行作为业务逻辑的操作？
除此之外，考虑到 Rob 的评论，我是否在使用 Oxite 作为学习基准时犯了错误？
您的业务逻辑进入您的业务层。控制器使用业务层为您的视图创建模型以进行渲染。Rob Conery 制作的 MVC Storefront 应用程序就是一个很好的例子。Oxite 目前受到很多负面报道，因为它显然没有很好地利用 MVC 框架。
您想要一个与控制器分离的业务层的原因是您可能希望跨多个控制器甚至多个应用程序重用业务层。这方面的一个例子是用于显示数据的普通用户功能，以及用于更新和添加数据的管理功能。您可以在这两种情况下使用相同的 BL 组件，但使用不同的控制器和视图来呈现数据。模型对象将是相同的。
您可以使用您的实体、聚合、存储库和服务来实现您的业务层（即模型）。服务调用存储库，它以实体的形式从 DAL 中提取数据。
这可以在一个单独的项目中设置，该项目只不过是一个 DLL。
接下来，让你的 MVC 应用程序，它实际上是你的表示层，并让它利用你的业务层项目。控制器将与您的服务一起使用，并将这些服务生成的数据泵入 ViewData，然后将其泵入您的视图。
控制器应该只处理路由问题，例如显示哪些视图，基于来自表单、查询字符串、cookie、会话等的用户输入。
“MVC 纯粹主义者”社区对 Oxite 被用作一个很好的 MVC 示例的有效性引起了轩然大波。底线是，业务逻辑不应该包含在控制器中，我相信随着 Oxite 在接下来的几个月里被重构，你会看到这一点。