Est-il un double travail crée un composant d'accès aux données et la composante de l'entreprise?

Question

Je conçois ma première application en couches qui se compose d'une des données, des affaires, et une couche de présentation.

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 semble être un double travail que je dois créer les composants d'accès aux données avec les méthodes de base ainsi que les composants d'affaires qui appelle simplement simplement les méthodes dans l'accès aux données des composants.

Quelle serait considérée comme meilleure pratique pour la mise en œuvre correctement les fonctionnalités de base CRUD dans une application en couches? Doivent-ils être « codés » dans le Composant ou dans un accès aux données de composants?

Answer 1

Cela dépend. Si vous prévoyez que votre couche métier tout simplement faire des opérations CRUD que vous pouvez suivre votre approche initiale. Si vous prévoyez d'utiliser une grande logique métier où volet commercial travaillera avec de nombreuses entités deuxième approche est meilleure.

La raison pour laquelle les gens aiment utiliser la deuxième approche est le test et l'ignorance de persistence. Si vous utilisez votre première approche composante de l'entreprise est étroitement lié à Entity Framework. Mocking ObjectContext n'est pas la tâche très facile si le test est difficile. Si vous utilisez votre deuxième approche couche d'affaires est indépendante sur la couche de persistence. Vous pouvez facilement tester et vous pouvez même changer la couche persistence si vous avez besoin. Mais ce sont des concepts plus avancés que vous cherchez probablement pas pour le moment. Votre code aurait besoin d'amélioration supplémentaire pour être testables.

DAC peut également être mis en œuvre 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 instanciation référentiel:

var repository = new GenericRepository<User>();

Il faut aussi savoir que l'utilisation de la couche d'accès aux données séparées introduit une nouvelle complexité parce que parfois il est raisonnable de partager contexte unique entre plusieurs référentiels. Cela vient avec quelque chose appelé Unité de modèle de travail.

Il y a beaucoup d'articles sur la mise en œuvre du référentiel et l'unité des modèles de travail sur Internet. J'ai certains d'entre eux comme favoris stockés à la maison, donc si vous êtes intéressé je peux les inclure à ma réponse plus tard.