我是否需要分离Business Objects和Business Logic?在C#中使用存储库模式的Asp.net MVC

时间:2015-08-16 21:00:29

标签: c# asp.net asp.net-mvc repository

我无法找到答案。基本上,现在我有这些层:

  • 数据访问层(我的存储库所在的位置)。它有Namespace Hello.Data
  • 业务层(我的业务对象所在的位置)。它有Namespace Hello.Business

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

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

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

所以而不是:

Hello.Data
Hello.Business

我会:

Hello.Data
Hello.Business
Hello.BusinessLogic

或者我认为这一切都错了?谢谢!

1 个答案:

答案 0 :(得分:1)

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

除了可能很小的通用实用程序库之外,业务逻辑层不应该引用任何东西。基本上,它应该不依赖于基础架构问题(如应用程序技术,数据库技术等)。它应该包含只是业务逻辑。

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

  

虽然这不起作用,因为我无法将数据访问层引用到我的业务层,并且我的业务层引用了我的数据访问层。

正确!此设计中的错误是业务逻辑层完全引用数据访问层 。它不应该。

然而, 包含用于数据访问层实现的数据访问(以及其他基础架构问题)的 interfaces 。业务逻辑层只需要知道接口,它不知道或关心实现这些接口的是什么。

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

  • 应用程序层引用依赖注入层来初始化它,并将容器(它本身实现通用业务逻辑接口)传递给业务逻辑层。
  • 依赖注入层引用业务逻辑层以了解接口,并引用数据访问(和其他基础结构)层以了解实现。
  • 数据访问(和其他基础架构)层引用业务逻辑层以了解要实现的接口。
  • 业务逻辑层不引用任何内容。它需要一个配置的依赖注入容器,并使用该容器来获取接口的实现。