Discussion :

[Liiscar]

Bonjour,

J'espere avoir mis au bon endrois, c'est de la conception mais fortement lié à C# et à EF.

Contexte:
Voila je me pose une question en tant que jeune architecte. Je travail souvent sur des projets ludiques qui me permettent de mettre en pratique des techniques, technologies, architectures etc.. Dans ce cas précis c'est un jeu basé sur des agents autonomes.
J'ai besoin d'une persistance des données en base de donnée type SQL.

Problèmatiques:
Je vois souvent la couche métier (Business BLL) utiliser directement les entités issus de la couche d'acces aux données (DAL). Objet DAL, j'ai envie de dire POCO mais pour moi EF permet déjà de récupérer des objets améliorés qui sont plus que de simples POCO?
On utilise donc des classes MonEntiteManager dans la couche BLL pour les manipuler. Ca marche bien pour des applications qui traitent des documents, la plupart des applications d'ailleurs.

Mon problème c'est que j'ai une application fortement orienté objet qui a été pensé de cette facon. Cela implique des entités actives qui évoluent bref qui utilisent beaucoup de conceptes objets.


Je voudrais avoir votre avis sur des bonnes pratiques:

1. Avec Manager
   Uiliser quand meme des "Manager" d'entités et travailler avec les entités du DAL et les manipuler. On perd les avantages d'une architecture orienté objet, il y a plus de MonEntite.Action(). Ca alourdi le code je trouve et on perd le coté intuitif naturel.
   Exemple:
   Voiture.Garer() devient VoitureManager.Garer(MaVoiture)
   
2. Utiliser partial
   Avec Entity Framework, les objets générés sont partial, peut-on dans la couche BLL leur ajouter des methodes? l'avantage c'est d'utiliser directement les objets générés par EF. Le problème je crois c'est de devoir les mettre dans le meme namespace? Du coup on peut plus séparer les couches.
   J'ai vu ca pour ajouter des propriétés calculés ou quelques methodes simples. Cette technique doit rester dans la couche DAL (meme namespace) pour améliorer de simple POCO en objet utilisable par la couche métier et a manipuler avec des managers pour ne pas mettre de logique métier trop lourde. Ca semble pas la solution dans mon cas.
   
3. 2 modeles
   
   • Héritage
     Ca ressemble au partial mais les objets récupérés directement par EF sont plus compatibles.
     
   • Encapsulation
     Dans le meme esprit on encapsule les objets DAL dans des objets BLL pour les décorer.
     
     Ca demande dans les 2 cas des conversions pour passer d'un modele à l'autre. J'aurai bien voulu éviter ca meme si ca semble la solution. Surtout si on a encore un ViewModel .. On peut avoir 3 fois la répétition de la meme entité finalement.
     
     
   
   
4. Methodes d'extension
   J'ai vu chez un client que dans quelques cas ils avaient utilisé des extentions pour rajouter des methodes. Ca marche pas si mal finalement mais ca fait beaucoup d'extensions pour tout faire. C'est peut etre pas le role des extensions?
   
5. Autres des idées?
   

Pour résumer: Meilleur pratique pour travailler avec des entités de meme nature dans des couches différentes?

[Liiscar]

Je me répond à moi meme, je pense que j'ai une mauvaise compréhension de la frontiere entre les entités dans les différentes couches.
C'est lié aussi à ma mauvaise compréhension de ce qu'est les objets POCO. Je pensais que ce qu'on appelle POCO c'est les objets généré par EF (ceux créés par la génération des .tt). Maintenant je suis plus sur du tout mais aprés tout c'est que des termes meme si il est important de tous parler le meme langage pour se comprendre.

Entité BD < =1= > Entité généré par EF < =2= > Entité Métier < =3= > Entité pour la Vue

lien 1: c'est l'entity framework qui gere tout ca
lien 2: c'est mon probleme, j'ai vu trop de projets sans ce lien qui utilisent directement les objets générés par EF. Doit-on faire aussi dans BLL un wrapper avec du mapping? quels patterns? quel best practice?
lien 3: pour plus tard

[Invité]

Avec la première version d'EF, les entités générées dérivent toutes de la classe EntityObject et ce qui ne facilitait pas la tâche pour les tests et aussi surtout ne permettait pas l'utilisation de classes existantes en tant qu'entité.
Avec la version 4 nous avons pas mal d'améliorations qui sont apportées comme la génération d'entités POCO qui ne dérivent pas de la classe EntityObject et surtout aussi la facilité de la réutilisation de classes existantes et les mappées au modèle EDMX.

La best practice veut qu'on ait des objets POCO donc :

• soit t'as déjà ton modèle (génératio à partir de l'approche Database First ou créer manuellement avec l'approche Model First) alors tu généres tes entités POCO
• soit tu utilises l'approche Code First

Ensuite dans les deux cas on travaille avec des entités POCO et la bonne pratique veut :

• qu'on sépare les responsabilités : tes classes POCO doivent être déplacées dans une nouvelle librairie qui sera référencée par la suite par ta couche DAL.
• qu'on utilise le pattern Repository (une recherche te permettra de savoir comme l'implémenter)

[Liiscar]

Merci ca répond à mon incompréhension sur les POCO. Je lisais parfois que les POCO etaient générés par l'EF et parfois non avec la mise en place de unitOfWork et Repository pour avoir les dit POCO.
Finalement ca dépend la version d'EF. Un POCO c'est comme le nom l'indique finalement qu'une bonne veille classe de base C# sans héritage.

J'utilise dans mon cas la derniere version j'ai sorti de l'edmx 2 fichiers de template:
- Model.tt => me genere mes POCO
- Model.Context.tt => me genere le Contexte d'acces aux données

si je comprend bien tu dis de mettre Model.tt qui génère les classes POCO dans une autre librairie? Mais l'edmx est lié aux templates, tout ca ne devrait pas etre dans le projet DAL? Peut etre juste les mettre dans un autre namespace?

Utiliser le pattern Repository mais dans la BLL? pour convertir mes POCO en objet metier plus complet?

Beaucoup de questions désolé

[Invité]

si je comprend bien tu dis de mettre Model.tt qui génère les classes POCO dans une autre librairie?

Oui c'est ça. Tu déplaces ce fichier dans une autre librairie. Tu l'ouvres et tu verras quelque part le chemin vers le fichier EDMX alors tu modifies ce chemin de façon relative au projet dans lequel se trouve le Model.tt.

Mais l'edmx est lié aux templates, tout ca ne devrait pas etre dans le projet DAL? Peut etre juste les mettre dans un autre namespace?

Je dis bien si tu utilises les objets POCO donc générés à partir de ton modèle EDMX alors fais ce que j'ai dit plus haut. Parce que si tu ne fais pas cela tu seras obligé de référencer ta couche DAL à la fois dans la BLL et dans le client (WPF, Silvelright etc) alors que la bonne manière est la suivante :

1. Ton modèle (contenant tes objets POCO) sera référencé par toutes les couches
2. Ta DAL sera référencée par ta BLL
3. Ta BLL sera référencée par ton UI

Utiliser le pattern Repository mais dans la BLL?

Oui.

pour convertir mes POCO en objet metier plus complet?

Je ne vois pas où se trouve l'intérêt de convertir des objets POCO.

[Liiscar]

OK
Du coup le DAL fait presque rien, il a l'edmx avec le contexte associé c'est tout.

Je ne vois pas où se trouve l'intérêt de convertir des objets POCO.

On revient à mon probleme du message de départ.
Dans la plupart des projets que j'ai croisé effectivement on utilise des "manager" pour modifier les objets du modele et ca marche tres bien.
On mélange pas Modele de action sur le modele.
Dans mon cas j'ai un projet très orienté objet et j'ai envie de faire monObjet.Action() avec une methode Action() completement BLL donc je veux l'ecrire dans la BLL. Pour enrichir mon objet de base je dois le faire heriter de l'objet de meme nature POCO.

On a donc 2 objets differents il faut le convertir. C'est dans le repository qui est dans la BLL que je me charge en plus de convertir?

Et comme je disais au début il y a plusieurs solutions.

[Invité]

Du coup le DAL fait presque rien, il a l'edmx avec le contexte associé c'est tout.

Tu voulais dire que la DAL ne contient pas grand chose. Qui t'a dit qu'elle ne fait rien ? Si elle qui communique avec ta base données non. Imagine un jour quand tu voudras ne plus utiliser EF mais NHibernate alors là c'est juste ta DAL qui change mais pas le model.

On revient à mon probleme du message de départ.
Dans la plupart des projets que j'ai croisé effectivement on utilise des "manager" pour modifier les objets du modele et ca marche tres bien.
On mélange pas Modele de action sur le modele.
Dans mon cas j'ai un projet très orienté objet et j'ai envie de faire monObjet.Action() avec une methode Action() completement BLL donc je veux l'ecrire dans la BLL. Pour enrichir mon objet de base je dois le faire heriter de l'objet de meme nature POCO.
On a donc 2 objets differents il faut le convertir. C'est dans le repository qui est dans la BLL que je me charge en plus de convertir?

En tout cas tout ce que je peux te dire c'est que EF POCO a été mis en place pour éviter aux développeurs d'utiliser les objets DTO qui étaient la conversion des objets POCOs. Donc si tu penses vouloir convertir encore ces objets POCOs je te dirai de faire des recherches, lire des tutos pour bien comprendre le pourquoi de l'existence de EF POCO avant de te lancer tête baissée.

[Liiscar]

Tu voulais dire que la DAL ne contient pas grand chose

tu crois pas si bien dire j'ai perdu ma réponse initiale en postant (bug ou connexion) et j'avais mis contient avant


Merci de ton aide, c'est les questions que je me pose effectivement.
Je suis tombé sur un terme que je connaissais pas Anemic domain model http://en.wikipedia.org/wiki/Anemic_Domain_Model Ca correspond bien a ce pour quoi EF POCO est adapté finalement, d'ailleurs il y a une référence sur les POJO.