我将承认我对MVC很新，我将开始这个问题。设计模式对我来说很有意义，但现在我正在探索ASP.NET MVC，一些建筑作品正在挑战我的先入为主的观念。学习是件好事。
我最近一直在使用Oxite作为学习工具，由创建ASP.NET MVC的company人员编写，因此是ASP.NET MVC的表面参考应用程序。
但今天我看到Rob Conery的a blog post about Oxite说：
Oxite团队的其中一件事 决定做的就是分开了 控制器和视图到另一个 我只能假设的项目是 业务逻辑的分离 查看逻辑。这可能导致一些 控制器的意思是混乱 处理申请流程 - 不是 必然是商业逻辑。
这引起了我的反响。这种分离是MVC的原则，因此是Oxite开发人员的错误，还是Rob的意见？如果业务逻辑属于模型，为什么Oxite团队将其置于控制器中？如果不在控制器中，如何执行 业务逻辑的操作？
除此之外，考虑到像Rob这样的评论，我是否误用Oxite作为学习基准？
答案 0 :(得分：2)
您的业务逻辑进入您的业务层。控制器使用业务层为要渲染的视图创建模型。一个很好的例子是Rob Conery制作的MVC Storefront应用程序。 Oxite目前受到很多糟糕的压力，因为它显然没有充分利用MVC框架。
您希望业务层与控制器分开的原因是您可能希望跨多个控制器甚至多个应用程序重用业务层。一个例子是用于显示数据的普通用户功能，以及用于更新和添加数据的管理功能。您可以在两种情况下使用相同的BL组件，但具有不同的控制器和视图以呈现数据。模型对象是相同的。
答案 1 :(得分：1)
您可以使用实体，聚合，存储库和服务实现业务层（即模型）。这些服务调用存储库，它以实体的形式从DAL中提取数据。
这可以在一个单独的单独项目中设置，它只不过是一个DLL。
接下来，拥有您的MVC应用程序，它实际上是您的表示层，并让它利用您的业务层项目。控制器将与您的服务一起使用，并将这些服务生成的数据泵入ViewData，然后将其输入您的视图。
控制器应该只处理路由问题，例如根据表单，查询字符串，cookie，会话等用户输入显示的视图。
来自“MVC纯粹主义者”社区的一个骚动是关于Oxite的有效性被用作一个好的MVC例子。最重要的是，业务逻辑不应该包含在控制器中，我相信你会看到Oxite在未来几个月内被重构。