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

Question

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

• 数据访问层（我的存储库所在的位置）。它有命名空间 Hello.Data
• 业务层（我的业务对象所在的位置）。它有命名空间 Hello.Business

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

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

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

所以而不是：

Hello.Data
Hello.Business

我会：

Hello.Data
Hello.Business
Hello.BusinessLogic

或者我认为这一切都错了？谢谢！

Answer 1

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

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

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

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

正确！这种设计的错误在于业务逻辑层完全引用了数据访问层。不应该。

然而，它应该包含接口，用于数据访问（和其他基础设施问题），这些接口由数据访问层实现。业务逻辑层只需要知道接口，它不知道也不关心什么实现了这些接口。

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

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