【发布时间】:2015-03-30 13:32:33
【问题描述】:
前提:
我正在练习领域驱动设计,我将我的解决方案分为 4 层:
- 表示层
- 用于 RESTful API Web 服务的 ASP.NET Web API 2 项目
- 用于文档和管理屏幕的 ASP.NET Web MVC5 项目
- 应用层
- 一个类库项目,负责从表示层获取命令并使用任何域服务
- 域层
- 包含业务模型和逻辑的类库项目
- 包含领域服务的类库项目
- 基础设施层
- 一个包含所有具体实现的类库项目,例如使用 Entity Framework 的 dataq 持久性、使用 Log4net 的日志记录、使用 Simple Injector 的 IoC 等
领域层只有一组为聚合定义的存储库接口,它取决于基础设施层中存在的实现数据访问机制来隐藏实现细节。
在本练习中,我决定使用实体框架数据库第一种方法。当然,基础设施项目中有一个app.config,其中包含一个连接字符串。
问题:
好的,我花了很多时间尝试分离所有关注点并专注于域模型。在表示层(即 API 和 MVC 项目)中,没有直接引用基础设施项目。并且已经设置了 IoC 容器,因此所需接口的所有具体实现都将被注入到控制器构造函数中。
例如,当我选择 API 项目作为启动项目并运行它时,我得到了
An exception of type 'System.InvalidOperationException' occurred in EntityFramework.dll but was not handled in user code.
Additional information: No connection string named 'xxxxxx' could be found in the application config file.
问题:
现在我明白了,如果我将实体框架安装到 API 项目中,将连接字符串从基础设施项目的 app.config 复制并粘贴到 API 项目的 web.config 中,一切都会奏效。但这打破了我们分离关注点的最初目的,不是吗?如果我们这样做,那么使用领域驱动设计并让表示层的数据访问技术无知又有什么意义呢?
我们不直接引用数据访问技术的直接实现(即使用dbContext 和Linq 的具体实现)的原因是我们可以轻松地将地下访问技术转换为其他技术。
那么正确的做法是什么?!!
我不想在我的表示层中安装实体框架,也不想到处复制连接字符串。我希望所有的数据访问和存储库的具体实现都存在于一个库中。
【问题讨论】:
-
将所有的 ORM 数据访问放在存储库中是不值得的。教条地分离关注点会产生比它解决的问题更多的问题。
标签: c# architecture asp.net-mvc-5 domain-driven-design entity-framework-6