Entity Framework et séparation des couches

J'essaie de travailler un peu avec Entity Framework et j'ai une question concernant la séparation des couches.

J'utilise généralement l'approche UI -> BLL -> DAL et je me demande comment utiliser EF ici.

Mon DAL serait généralement quelque chose comme

GetPerson(id)
{
    // some sql
    return new Person(...)
}

BLL:

GetPerson(id)
{
    Return personDL.GetPerson(id)
}

UI:

Person p = personBL.GetPerson(id)

Ma question est maintenant: puisque EF crée mon modèle et DAL, est-ce une bonne idée d'envelopper EF dans mon propre DAL ou est-ce juste une perte de temps?

Si je n'ai pas besoin d'envelopper EF, est-ce que je placerais toujours Model.esmx dans sa propre bibliothèque de classes ou serait-ce bien de le placer à l'intérieur de mon BLL et d'y travailler?

Je ne vois pas vraiment la raison d'envelopper EF dans mon propre DAL mais je veux savoir ce que font les autres.

Donc, au lieu d'avoir ce qui précède, je laisserais de côté le DAL et je ferais simplement:

BLL:

GetPerson(id)
{
    using (TestEntities context = new TestEntities())
    {
            var result = from p in context.Persons.Where(p => p.Id = id)            
                    select p;
    }
}

Que faire?

L'exemple que vous fournissez n'est pas une architecture en couches. Je sais que c'est intentionnellement simplifié, mais:

Votre couche de présentation est directement liée à l'entité Personne. Ce n'est OK que dans les cas les plus simples, et certainement pas lorsque vous essayez de définir vos calques.

La méthode GetPerson utilise également une assez mauvaise pratique de création d'un nouveau contexte pour chaque appel. Vous devriez obtenir le contexte dans le constructeur, et il sera fourni par votre conteneur IOC.

Une structure simple mais efficace que j'ai utilisée est:

• Project.Core - contient des modèles de vue et des interfaces.
• Project.DAL - avec mon EDMX et le code généré.
• Project.BLL - logique métier.
• Project.Web - l'application Web elle-même.

Il est important de noter que:

• Le noyau ne dépend d'aucune autre solution.
• DAL ne dépend d'aucune autre solution.
• Project.Web dépend de Core, mais pas de DAL ni de BLL.
• BLL dépend de Core et DAL.

Vous n'avez pas besoin d'envelopper votre EDMX dans quoi que ce soit.

Si vous pouvez prévoir la possibilité de devoir passer d'EF à une autre approche, vous souhaiterez peut-être étendre vos objets métier (en profitant des classes partielles) pour implémenter des interfaces définies dans une couche d'objet métier distincte.

Ensuite, à partir de votre code, vous ne vous occuperez que de ces interfaces et non des classes générées concrètement. Un petit code de colle pourrait être nécessaire pour maintenir cela ensemble; cela avec l'EDMX peut être votre DAL.

Il existe deux approches générales de la superposition: la superposition stricte et la superposition détendue.

Une approche strictement stratifiée contraint les composants d'une couche à n'interagir qu'avec les pairs et avec la couche directement en dessous.

Une application en couches détendue relâche les contraintes de sorte qu'un composant peut interagir avec les composants de n'importe quelle couche inférieure.

L'utilisation d'une superposition détendue peut améliorer l'efficacité car le système n'a pas à transférer les appels simples d'une couche à la suivante. D'un autre côté, l'utilisation de couches détendues ne fournit pas le même niveau d'isolation entre les couches et rend plus difficile le remplacement d'une couche inférieure sans affecter les couches supérieures.

Pour les grandes solutions impliquant de nombreux composants logiciels, il est courant d'avoir un grand nombre de composants au même niveau d'abstraction qui ne sont pas cohérents. Dans ce cas, chaque couche peut encore être décomposée en un ou plusieurs sous-systèmes cohésifs. La figure 2 illustre une notation UML (Unified Modeling Language) possible pour représenter des couches composées de plusieurs sous-systèmes.

conclusion: si vous n'avez pas besoin de la couche intermédiaire, perdez-la; toutes les applications ne nécessitent pas la même approche et, en quelque sorte, l'ajout d'une couche uniquement à des fins de superposition entraînera des pénalités sur le coût de la complexité et la maintenance.