领域驱动设计+EF 的分层问题(转载csdn上面的 因为我也有同样问题)
0
悬赏园豆：60
[已关闭问题]
关闭于 2011-06-16 17:24
最近在下为一个项目做初步设计，由于业务逻辑比较复杂，最后决定使用领域驱动方式，系统的数据处理使用Entity Framework但在分层上遇到问题。
在以往的开发中，无论使用传统的SQL还是NHibernate,在Model层里面，一般每个表都会有对应值对象，这是数据传送的基础。但当使用Entity Framework，会将数据层的对象模型与业务层的对象模型结合。所以我被迫把Model层与BLL层结合起来放在领域层上。
partial class People{..........}
//既存在People的所有属性，又会在其中加入适当的逻辑关系。
在一般的领域驱动设计中，我们会在领域层先设置IRepository接口，再把Repository放在Infrastruction层里面实现。但因为Repository是管理Model的存取的，所以在Infrastruction必先引用领域层。（这正是问题所在，在下觉得有点违反设计规律，引用似乎倒置了。）
现在问题出现了，因为传统的开发会在DAL层中把数据表数据转化为对应的Model，而现在Model先经成为值对象与领域模型的组合。现在领域层调用对应的Repository时，我们必须使用反射创建，建立一个RepositoryFactory，而现在RepositoryFactory被迫放在领域层。（如果把RepositoryFactory放在Infrastruction层，引用时会导致双向引用出错）
而在日后的开发过程中，我们会有更多的类似问题，本来应该放在Infrastruction的类，被迫放进了领域层，以置分层不够明确。这都是因为我们把Model与领域模型合并的原因。
传统的设计应该是由领域层去引用各个基础设施以配合实现的。但Entity Framework引入后却适得其反，多个底层都必须依赖领域层中的model，请教各位有何好对策可以与在下分享一下。
所有回答(3)
0
IRepository和Repository不是一回事的。
IRepository是一种契约，Repository是一种实现，针对契约的实现。
以前我们的BLL,DAL是怎么产生的呢？估计有时候都是生成的，造成了每张表一个DAL，BLL中的很多方法都只是依据dal.get()之类的代码，其他都没有了。有的里面可能会有一些逻辑判断，然后如果逻辑判断需要重用呢？好吧，写一个类，好吧，写一个静态类。在静态方法中使用业务对象的很多属性来判断是否满足条件。造成业务逻辑和业务对象分离，其实有些业务逻辑是属于对象的。同时还造成业务对象过分的暴露自己的数据（都是get；set；）。
还有就是以前的DAL中包含了几乎所有的数据库操作，然后BLL需要实现一种业务的时候，就从DAL中挑选几个组合一下，就是实现了业务。
IRepository代表一种契约，一种领域层的需要。首先领域层会以契约的形式，也就是接口，定义自己的需要，自己对于持久化的需要。然后具体的持久化，是持久化到db还是file，还是其他什么形式，由实现者repository来做主。
0
你的IRepository是应该放在Domain层的，而Repository的具体实现则必须是放在基础结构层的，你说的没错，Repository所在的基础结构层组件需要引用Domain的Assembly，而既然是基础结构层，那么Domain的Assembly也自然是可以引用基础结构层的，这就产生了循环引用。
事实上，你的Repository的具体实现是通过IoC容器注射到你的Domain层的，而不是由Domain直接通过添加引用来实现的。你可以把有关Repository的实现的类放在一个单独的基础结构层项目中，比如Infrastructure.Repositories.dll，这个Assembly引用Domain的Assembly，而在Domain中，则使用IoC容器来获得Repository的实例。
请参考我写的这篇文章：http://www.cnblogs.com/daxnet/archive/2010/07/07/1772780.html
0
