Entity framework - Data access layer - Isollement?

Bonjour

Alors voilà, je voulais apprendre à mieux structurer mes projets et donc je me suis dit qu'utiliser une data access layer est quand même le minimum.
D'après divers code qu'on trouve sur le net, la définition des classes à mapper en base de donnés (avec Entity Framework), se trouve bien isolée du reste, ce qui est très bien.

Mais du coup un problème se pose.
J'ai besoin de propriétés dans ces classes mais qui ne soit pas mappées en base de donnés. Alors techniquement aucun soucis avec EF, suffit de le paramétrer correctement.

Néanmoins on casse un peu l’isolement des différentes couches.

C'est quoi la meilleurs manière de faire???
utiliser des classes en couche business qui hérite de son équivalent en couche DAL?

Alors je précise que j'ai également trouvé des design qui utiliser automapper entre les couches, j'ai pas regardé dans le détail, mais je dirait qu'il est possible de rajouter des propiété à la classe dans la couche business sans que son équivalent dans la couche DAL n'en soit impacté, mais je préfère avoir votre avis.

Merci :P

Salut,

Alors premier point: heriter des classes DAL c'est beau dans la theorie mais dans la pratique cela souleves ques problemes:

• si tu exposes ces objects tu restes couple avec la dal
• tu as une relation d'heritage 'technique' mais pas fonctionnelle ce qui est sematiquement faux
• si tu as besoin d'avoir des proprietes pas exposee mais qui sont dans la dal tu fais comment ?

<= Donc a mon sens c'est une mauvaise idee (malheureusement subie).


La technique d'avoir une 'copie' de ton objet DAL est 'propre' mais pas beaucoup mieux:

• tu copies les champs mais avec quelle profondeur d'objet ?
• tu ajoutes un decouplage pour la gloire, mais si tu changes dans la dal il faut change le model et vice versa.
• les tables d'assos n-n et autres tables technique tu fais comment ?

<= version testee et pas convaincu.

La troisieme solution est de revoir sa copie d'archi et plus de se concentrer sur le model/metier que sur la sparation cf archi onion/hexagonal. Mais cela revient a changer profondement sa maniere de penser. Il n'y a plus de couches mais des services que tu branches. J'ai vu un tuto sur dvp il y a quelques mois sur le mapping des objet justement: http://aurelien.boudoux.fr/2014/09/l...es-pierre.html

<= mais je n'ai pas encore utilise ce genre d'archi sur un projet pro.


Voila, il y a aussi la version crado mais qui fait le taff de mettre tout dans tes classes entity.

a mon sens toutes les versions ont leurs point forts, a toi de voir avec la taille du projet l'equipe qui bosse dessus, le budget alloue etc.

Moi je ferai

• crado pour un projet perso=>3 developpeurs
• verison solid, pour une equipe motivee qui a peur de rien
• version copie dans le reste des cas.

Le problème avec EF c'est que tes entités sont générées automatiquement. Et il peut être difficile de reprendre le contrôle sur le SQL généré. Partant de là difficile de garder la main sur tout.

Sur mes derniers projets en tant que développeur, j'ai utilisé la DAL proposée par Rudy Lacovara. Il a écrit une série de 3 articles, qui ont été traduits par notre ami rv26t :
- http://rv26t.developpez.com/tutoriel...bject-partie1/
- http://rv26t.developpez.com/tutoriel...bject-partie2/
- http://rv26t.developpez.com/tutoriel...bject-partie3/

Les gains sont perceptibles : bon découpage des couches, il est facile de rajouter de l'injection de dépendance pour réduire le couplage - et donc des tests unitaires, la maintenance est relativement simple et les performances sont optimales.

Comme l'a indiqué mermich une nouvelle tendance actuellement est de partir sur une architecture en oignon, mais difficile de prédire si cette tendance va réellement être suivie ou non. Pour sûr elle demande une autre facon de penser et à long terme difficile de prédire les impacts.

Depuis que je suis CTO, j'encourage mes architectes à promouvoir la couche d'accès aux données ordinale classique sur la plupart des projets. Cependant pour les plus petits projets (souvent jetables) où l'architecture et les perfo ne sont pas trés importantes, en général il est plus simple d'utiliser EF : gain de temps net.

Bonjour,

Cette réponse est peut-être tardive, mais je pense que ces informations pourront aider d'autres développeur par la suite.

Les dernières guidelines données par EF & MS en terme de conception de base de donnée à légèrement changé. En effet, la conception de base de donnée doit maintenant se faire via du "code first" ( pour la simplicité de portage vers de nouvelle plateforme ), ainsi la certains problèmes évoqués sont "résolu" ( entité généré automatiquement, propriété de classe non mappé )

Il suffit ensuite d'utiliser les injections de dépendance et les repository pour correctement isolée sont code.

Ce n'est pas forcement la solution parfaite à utiliser dans tout les cas, mais elle peut dans le cadre de projet à taille modérer de correctement architecturer sont code sans passé par une architecture SOLID comme mentionné plus tôt par exemple.

Voilà en espérant que ça aide :)