Questions concernant Entity Framework + DDD

Question

J'ai du mal à trouver des exemples simples d'utilisation de EF dans un modèle de style DDD. C'est aussi la première fois que j'utilise DDD et j'ai quelques questions concernant la disposition de la solution et comment utiliser certains des modèles DDD.

1) La plupart des exemples que j'ai vus concernant l'utilisation du modèle Repository w/EF montrent simplement des interfaces Modèle spécialisées telles que IContactRepository, puis un type concret implémentant l'interface. Idéalement, j'aimerais utiliser quelque chose comme IRepository qui a un ensemble de fonctionnalités de base pour les opérations CRUD. Je pourrais alors créer des dépôts spécialisés si nécessaire tel que IContactRepository: IRepository si nécessaire car la plupart de mes modèles n'auront pas besoin d'être étendus. Est-ce que j'aboie le mauvais arbre? Quelqu'un peut-il me fournir des exemples de ce style de mise en œuvre? 2) À l'heure actuelle, ma solution est divisée en trois projets: Modèles (contient mon EDM), Dépôts et Services. Est-ce que c'est approprié ou est-ce qu'il y a une autre approche de mise en page que je ne considère pas et devrait être?

3) J'ai vu des exemples de dépôts ayant des méthodes Query (Func <T>)/Query() qui retournent IQueryable. Est-ce malodorant ou quelque chose de mal vu?

Answer 1

Je voudrais répondre # 3 ...

Je pense qu'il est moins "malodorant" et plus "paresseux". Voici un typique « dépôt » que j'ai été voir dans les internets ...

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); 
} 

Pour autant que je sache, ce qui est moins un dépôt et plus une « session » ou « unité de travail » . C'est un moyen pratique de faire abstraction de la technologie de base de données que vous utilisez et de simplement parler à une interface extrêmement générique à la place. Donc, renommons-le en ISession, à la place. C'est le modèle que j'ai fait récemment.

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); 
    } 
} 

Dans cette configuration, le ISession est un lien générique au magasin de données. Le PersonRepository, cependant, est très spécifique aux types de requêtes et d'actions qui sont effectuées sur un objet Person.

Espérons que cela aide.

Answer 2

Voici un exemple:

http://dataguidance.codeplex.com/

Answer 3

Nous utilisons actuellement EF avec DDD, mais je dois dire que dans sa mise en œuvre actuelle, EF est pas très approprié à ce genre d'architecture. Le problème principal est que la seule façon dont EF fonctionne actuellement est que chaque 'Entité' dérive d'une classe de base spécifique à EF. D'autre part, le point sur les dépôts est résumé la technologie d'accès aux données. L'idée derrière DDD est que le modèle de domaine devrait être non contraint par des détails d'implémentation tels que le choix de la technologie d'accès aux données. Cela signifie que les objets de domaine doivent être définis de façon à être Persistant-Ignorant. En d'autres termes: Vous ne pouvez pas utiliser les EF 'Entities' comme objets de domaine, donc dans votre DAL, vous devez écrire manuellement beaucoup de code mappant vers et depuis les objets de domaine vers les 'Entités' EF. Ça me fatigue vraiment vite.

Je considérerais certainement avoir IQueryable sur un référentiel comme une abstraction qui fuit, et cela n'a pas beaucoup de sens dans le langage DDD. Si les objets de domaine sont des unités cohésives, cela n'a pas beaucoup de sens de ne sélectionner que certaines «colonnes».

Dans EF pour .NET 4.0, nous obtiendrons la persistance ignorance, il devrait donc être mieux à l'avenir ...