控制器处理应用程序流程，所以我的业务逻辑走向何方？

Question

我会开始这个问题，承认我对MVC很陌生。设计模式对我来说很有意义，但现在我正在探索ASP.NET MVC，其中一些架构片断正在挑战我的先入为主的观念。学习是一件好事。

最近我一直在使用Oxite作为一个学习工具，由company创建的ASP.NET MVC人员编写，因此也是ASP.NET MVC的一个表面参考应用程序。今天

但是我看到a blog post about Oxite通过罗布科纳，说：

的事情之一是，Oxite团队 决定这样做是对 控制器和视图分离到另一个 项目什么，我只能假设是 将业务逻辑从 视图逻辑中分离出来。这可能导致一些 混淆，因为控制器意味着 来处理应用程序流 - 而不是 必然的业务逻辑。

这引发了我一个循环。这种分离是MVC的宗旨，因此是Oxite开发者的错误，还是Rob的观点？如果业务逻辑属于模型，那么为什么Oxite团队将其放入控制器？如果不在控制器中，我如何执行为业务逻辑的操作？

此外，考虑到Rob's的评论，我是否在使用Oxite作为学习基准时犯了一个错误？

Answer 1

您的业务逻辑进入您的业务层。控制器使用业务层为您的视图创建模型。一个很好的例子就是Rob Conery生产的MVC Storefront应用程序。目前Oxite正在得到很多糟糕的新闻，因为它显然没有很好地利用MVC框架。

您希望独立于您的控制器的业务层的原因是您可能需要跨多个控制器甚至多个应用程序重用业务层。一个例子是显示数据的正常用户功能，以及用于更新和添加数据的管理功能。在这两种情况下，您可以使用相同的BL组件，但使用不同的控制器和视图来呈现数据。模型对象将是相同的。

Answer 2

您可以使用您的实体，聚集，存储库和服务来实现您的业务层（即模型）。服务调用存储库，以实体形式从DAL提取数据。

这可以设置在一个单独的项目中，它只不过是一个DLL。

接下来，让您的MVC应用程序，它真的是您的表示层，并让它利用您的业务层项目。控制器将与您的服务一起工作，并将这些服务生成的数据抽取到ViewData中，然后将其抽入您的Views。

该控制器应该只处理路由问题，如该视图中显示，基于来自形式，查询字符串，饼干，会话用户输入等

一直存在噪从“MVC纯粹主义者”社区关于Oxite被正确使用的一个很好的MVC例子。底线是，业务逻辑不应包含在控制器中，我相信你会看到Oxite在未来几个月被重构。