有关实体框架+ DDD的问题

我很难找到在DDD样式模式中使用EF的直接例子。这也是我第一次使用DDD，并且有关于解决方案布局以及如何使用某些DDD模式的几个问题。有关实体框架+ DDD的问题

1）我见过的有关使用存储库模式w/EF的大多数示例仅显示专用模型接口，如IContactRepository，然后是实现接口的具体类型。理想情况下，我喜欢使用像IRepository这样的具有CRUD操作的基本功能集的东西。然后，我可以创建专门的存储库，如果有必要的话，比如IContactRepository：IRepository需要的时候，因为我的大多数模型不需要扩展。我吠叫错了树吗？有人能为我提供这种实施方式的例子吗？

2）现在我已将我的解决方案分解为以下三个项目：模型（包含我的EDM），存储库和服务。这是合适的还是有另一种布局方法我不考虑，应该是？

3）我已经看过存储库的例子，它有一个返回IQueryable的Query（函数<T>）/ Query（）方法。这是臭或有什么皱眉？

来源

2009-10-06 James Alexander

我想回答＃3 ...

我认为这是少“臭”，更“懒”。下面是一个典型的“资源库”，我已经看到周围的互联网络...

public interface IRepository { 
    // Query operations. 
    IQueryable<T> All<T>(); 
    IQueryable<T> Find<T>(Expression<Func<T, bool>> expression); 
    T Single<T>(Expression<Func<T, bool>> expression); 

    // Save operations. 
    T Add<T>(T objectToAdd); 
    void Delete<T>(T objectToDelete); 
    T Update<T>(T objectToUpdate); 
}

据我所知，这是少了仓库，并多了一个“会议”或“工作单位” 。这是一种方便的方法，可以将您正在使用的任何数据库技术抽象出来，而只是转而使用非常通用的接口。所以让我们将其重命名为ISession。这是我最近一直在做的模式。

public class PeopleRepository { 
    private readonly ISession session; 

    public PeopleRepository(ISession session) { 
    this.session = session; 
    } 

    public virtual IEnumerable<Person> Active() { 
    return session.Find<Person>(p => p.Active).OrderBy(p => p.LastName).ThenBy(p => p.FirstName); 
    } 

    public virtual IEnumerable<Person> ByLastName(string name) { 
    return session.Find<Person>(p => p.Active && p.LastName.StartsWith(lastName)).OrderBy(p => p.LastName).ThenBy(p => p.FirstName); 
    } 

    public virtual void DeletePerson(int personId) { 
    // We don't really delete people; we mark them as inactive. 
    var person = session.Single<Person>(p => p.Id == personId); 
    person.Active = false; 
    session.Update(person); 
    } 
}

在此设置中，ISession是数据存储的通用链接。但是，PersonRepository对于在Person对象上执行的查询和操作的类型非常具体。

希望这会有所帮助。

来源

2010-12-28 14:33:25

我现在也是这种方法的粉丝。感谢您的比较和解释。 – 2010-12-28 15:56:22

这里有一个例子：

http://dataguidance.codeplex.com/

来源

2009-10-06 21:52:18

这没有回答我的问题，实际上为我创造了更多。数据访问指导项目也基于VS2010。 – 2009-10-07 13:59:07

目前我们使用EF与DDD，但我不得不说，在目前的实现，EF也不是很适合这种体系结构。主要的问题是EF目前的唯一工作方式是让每个“实体”都来自EF特定的基类。另一方面，关于知识库的整个观点是将摘要带走了数据访问技术。 DDD背后的全部理念是，通过实施细节（如数据访问技术的选择），域模型应该是unconstraind。这意味着域对象应该被定义，以便它们是持久性无知的。

换句话说：您不能使用EF'实体'作为域对象，因此在您的DAL中，您必须手动编写大量代码来映射域对象和EF'实体'。这真的很累了。

我肯定会考虑让一个存储库上的IQueryable成为一个漏洞抽象，并且它在DDD说法中没有多大意义。如果域对象是有凝聚力的单元，那么从它们中只选择某些“列”并不是很有意义。

在EF的.NET 4.0，我们将获得持续性的无知，所以它应该成为今后更好...

来源

2009-10-07 03:25:40

有关实体框架+ DDD的问题

回答

相关问题