MVC中是否有业务层？

Question

什么时候在mvc Web应用程序中有一个业务层？为什么来自控制器的调用会直接进入dataaccess层？

Answer 1

  

什么时候在mvc Web应用程序中有一个业务层？

如果您想要重用某些现有或复杂的业务逻辑，这可能会派上用场。显然，这并不意味着您应该在每个应用程序中始终拥有业务层。这取决于应用程序的具体要求并回答这个问题，而没有关于您的场景的更多细节将是主观的。

所以，如果你想要一个客观的答案，请提供一个客观的场景，否则我们只是在这里喋喋不休而不是建设性的。

  

为什么从控制器直接调用数据访问层？

不知道，恕我直言，这会使你的控制器与你的数据库紧密耦合，因此难以进行单元测试。如果明天你决定改用可能怎么办？你想修改你的控制器吗？我建议你通过总是使用抽象（抽象类/接口）来使应用程序的不同层尽可能地弱耦合。

Answer 2

请记住，MVC框架只是一个表示层。如果您看到维基百科，您将意识到模型基本上是域层，并且应该在那里处理所有业务逻辑。

关于控制器是否应该直接引用数据库，有几种理论。还有一种趋势出现Repository pattern is evil。

要使控制器精简且可测试，您可以考虑实现控制器调用的service layer。

Answer 3

在您的应用程序中创建业务层总是有帮助的。对于一些非常简单的应用程序，除了CRUD之外没有其他功能，EF或LINQtoSQL生成的对象可以用作业务对象。只有当应用程序非常简单时，才能接受在控制器中嵌入数据访问调用的唯一时间。

Answer 4

模型是mvc

中的业务层 编辑（还有点咆哮）：我对MS产品的体验因MVC v1而停止。那时候，你的模型是由L2S或EF或其他人生成的。我知道MVVM在mvc中非常流行，但是这种模式表明支持视图的东西是视图模型，而业务逻辑的东西就是模型。 Rails，merb，django，symphony，backbone.js以及我所知道的所有其他mvc框架都调用了你将业务逻辑放在模型中的东西，当你去维基百科并查找mvc时，你会看到它有这个说关于模型

  

该模型管理行为和   应用程序域的数据，   响应信息请求   关于它的状态（通常来自   查看），并响应指令   改变状态（通常来自   控制器）。在事件驱动系统中，   模型通知观察者（通常   视图）当信息发生变化时   他们可以做出反应。

并不意味着成为一个混蛋，但如果ASP.net MVC正在调用视图模型模型，他们使用的术语不正确，并且完全失去了他们之后命名为框架的模式。

Answer 5

当您的逻辑既不关心特定Web事务的控制流，也不涉及特定域对象的数据访问。请参阅MSDN关于ASP.NET MVC单元测试的白皮书的这一部分：

http://msdn.microsoft.com/en-us/magazine/dd942838.aspx#id0420058

Answer 6

我建议使用存储库模式将数据访问的详细信息与控制器分开。您不一定需要整个业务层 - 除非您有一个包含许多自定义规则的复杂域。但是，您可能应该将存储库接口和类保存在单独的库中，以便对存储库的单元测试不使用Web层（您可以在那里测试控制器）。

以下是使用工作单元和存储库模式与实体框架的一个很好的示例：

http://blogs.microsoft.co.il/blogs/gilf/archive/2010/06/21/revisiting-the-repository-and-unit-of-work-patterns-with-entity-framework.aspx

Answer 7

当我编写我的.NET代码时，作为一名应用程序开发人员 - 这并不是说要夸大我自己的自我，而是说我的主要目标是编写不可避免地要扩展和改变的应用程序再次。

因此，我将我的模型代码编写到子文件夹，BOL和DAL下。

DAL处理所有数据库代码 - 使用BaseDAL，它具有获取RETURN VALUES（有和没有数据集）的数据集和函数的功能 - 我只使用存储过程。

BOL，模拟实际对象，每当我想要数据库中的数据时，我都会调用相关的DAL。因此，BOL是实际的BOL，我可以随时更改DAL。

分离是良好发展的关键，在我看来，将BOL与DAL分开是很有道理的。你不应该从控制器进行db调用，这是完全错误的，恕我直言。

Answer 8

  

关于MVC中的MV   ASP.NET / MVC明确指的是   视图模型

• 真的？那么V在ASP.NET / MVC中代表什么呢？