我需要分离业务对象和业务逻辑吗?Asp.net MVC与c#中的存储库模式

本文关键字：业务 MVC net 模式 存储 Asp 分离 对象 | 更新日期: 2023-09-27 18:08:16

我很难找到答案。基本上，现在我有这些图层:

  • 数据访问层(我的存储库所在)。它具有命名空间Hello。数据
  • 业务层(业务对象所在的位置)。它具有命名空间Hello。业务

我的存储库将返回业务对象。例如，GetCustomer将返回Customer。

然而，在我的业务层，我还想添加逻辑，将使用存储库来添加/更新/删除记录，所以我可以在我的MVC控制器中重用这些方法。这不起作用，因为我不能让我的数据访问层引用我的业务层，也不能让我的业务层引用我的数据访问层。(它创建了一个不允许的循环引用)。

你们认为最好的解决方案是什么?我应该把我的业务逻辑放到它自己的项目中吗?

所以不是:

Hello.Data
Hello.Business

我要:

Hello.Data
Hello.Business
Hello.BusinessLogic
还是我想错了?谢谢!

我需要分离业务对象和业务逻辑吗?Asp.net MVC与c#中的存储库模式

为什么要将业务逻辑与业务模型分开?逻辑应该在模型中。

业务逻辑层不应该必须引用任何东西，除了可能是小的公共实用程序库。基本上，它不应该依赖于基础设施(如应用程序技术、数据库技术等)。它应该只包含业务逻辑。

所有其他层都应该引用业务逻辑层。

这不起作用，因为我不能让我的数据访问层引用我的业务层，也让我的业务层引用我的数据访问层。

正确!这种设计中的错误在于业务逻辑层根本没有引用数据访问层。这是不应该的。

然而，

它应该包含接口用于数据访问(和其他基础设施关注)，这些接口由数据访问层实现。业务逻辑层只需要知道接口，它不知道或关心是什么实现了这些接口。

然后使用依赖注入容器将实现连接到接口。

  • 应用层引用依赖注入层对其进行初始化，并将容器(其本身实现了通用业务逻辑接口)传递给业务逻辑层。
  • 依赖注入层引用业务逻辑层来了解接口，引用数据访问(和其他基础设施)层来了解实现。
  • 数据访问(和其他基础设施)层引用业务逻辑层来了解要实现的接口。
  • 业务逻辑层不引用任何东西。它需要一个配置好的依赖注入容器，并使用该容器来获取接口的实现。
相关文章：