S'agit-il d'un double travail de création d'un composant d'accès aux données et d'un composant métier?

Question

Je conçois ma première application Layered qui consiste en une couche Data, Business et Presentation.

Mes composants métier (par exemple, Business.Components.UserComponent) a actuellement la méthode suivante:

public void Create(User entity) 
{ 
    using (DataContext ctx = new DataContext()) 
    { 
     ctx.Users.AddObject(entity); 
     ctx.SaveChanges(); 
    } 
} 

J'aime cette conception. Cependant, j'ai rencontré quelques exemples en ligne qui recommande la mise en œuvre suivante:

public void Create(User entity) 
{ 
    // Instanciate the User Data Access Component 
    UserDAC dac = new UserDAC(); 
    dac.InsertUser(entity); 
} 

Cela aboutirait à la création d'un accès aux données de composants pour toutes les entités, chacune contenant les méthodes de base (Créer, modifier, supprimer ... etc).

Cela ressemble à un double travail car je devrais créer les composants d'accès aux données avec les méthodes de base ainsi que les composants métier qui appellent simplement les méthodes dans le composant d'accès aux données.

Quelle serait la meilleure pratique pour implémenter correctement les fonctionnalités de base CRUD dans une application en couches? Doivent-ils être «codés» dans la composante commerciale ou dans une composante d'accès aux données?

Answer 1

Cela dépend. Si vous vous attendez à ce que votre couche métier effectue simplement des opérations CRUD, vous pouvez suivre votre approche initiale. Si vous prévoyez d'utiliser une logique de grande entreprise où le composant métier fonctionnera avec de nombreuses entités, la deuxième approche est préférable.

Raison pour laquelle les gens aiment utiliser la deuxième approche est le test et la persistance de l'ignorance. Si vous utilisez la première approche, votre composant métier est étroitement associé au framework Entity. Se moquer d'ObjectContext n'est pas une tâche très facile, donc tester est difficile. Si vous utilisez une seconde approche, votre couche de gestion est indépendante de la couche de persistance. Vous pouvez facilement le tester et vous pouvez même changer la couche de persistance si vous en avez besoin. Mais ce sont des concepts plus avancés que vous ne cherchez probablement pas pour le moment. Votre code aurait besoin d'améliorations supplémentaires pour être testable. DAC peut également être implémenté en tant que référentiel. Il y a beaucoup de façons comment créer du référentiel générique afin que vous ayez une seule classe et que vous définissez le type d'entité lorsque référentiel instanciation:

var repository = new GenericRepository<User>(); 

Sachez également que l'utilisation de la couche d'accès aux données séparées introduit une nouvelle complexité, car il est parfois raisonnable de partager un seul contexte entre plusieurs référentiels. Cela vient avec quelque chose de connu sous le nom de modèle d'unité de travail.

Il existe de nombreux articles sur l'implémentation des modèles Repository et Unit of work sur Internet. J'ai certains d'entre eux stockés comme favoris à la maison donc si vous êtes intéressé, je peux les inclure à ma réponse plus tard.