10 décembre 2008

POCO avec Entity Framework (1/2)

Qu'est-ce que POCO déjà ?

Cela signifie Plain Old Code Object. Le "C" peut vouloir dire aussi CSharp ou CLR Object. Dans le monde Java on retrouve ainsi l'acronyme POJO qui veut dire Plain Old Java Object, mais le sens est le même.

POCO signifie de laisser tel quel ses classes métiers lorsqu'on souhaite les rendre persistantes avec un outil de mapping objet-relationnel. C'est à dire que les classes métiers ne sont pas modifiées pour les faire fonctionner avec l'outil.

Entity Framework fonctionne avec des entités. Ce sont des classes dérivant de la classe System.Data.Objects.DataClasses.EntityObject. Une autre solution est d'implémenter 3 interfaces fournies par le framework .Le problème avec ce design, c'est que les classes métiers doivent être modifiées pour fonctionner avec Entity Framework. Du coup, on en déduie qu'Entity Framework ne supporte pas le concept POCO, en tout cas pas dans sa version 1.

L'équipe d'Entity Framework travaille sur une solution afin d'annuler la dépendance qu'il existe entre les classes métiers et le framework. Vous trouverez une partie de leur reflexion sur un de leur blog.

Une autre solution appellée PostSharp4EF a été proposée par Ruurd Boeke. Celle-ci est plutôt élégante car elle utilise la programmation orientée aspect (avec Postsharp) pour implémenter lors d'une 2ème compilation les interfaces requises pour rendre persistentes nos classes POCO.

PostSharp4EF exécute entre autres les tâches suivantes :
  • implémente les interfaces IPOCO : IEntityWithChangeTracker, IEntityWithKey et IEntityWithRelaships
  • Ajoute l'attribut EdmEntityType sur la classe, l'attribut EdmScallarProperty sur chaque propriété, l'attribut EdmRelashionShip et EdmSchema sur l'assembly

Toutes ces tâches sont exécutées grâce à PostSharp et à l'attribut [assembly: Poco("InheritanceTypeConnection")], celui-ci étant implémenté par PostSharp4EF.

Nous verrons dans un prochain billet un petit exemple d'implémentation.

3 commentaires:

Anonyme a dit…

Bonjour,
j'avais une petite question concernant votre (super) tutoriel sur developpez.com.
Est-ce que l'entity framework permet de générer les tables depuis le modèle conceptuel objet? C'est à dire comme Hibernate le fait, rester en modélisation objet sans avoir à faire quoique ce soit en base. merci d'avance, bruno

Popul a dit…

Désolé bruno,

Entity Framework ne gerera cette fonctionnalité que dans sa prochaine version (http://blogs.msdn.com/efdesign/archive/2008/09/10/model-first.aspx).

LinQ to SQL le permet par contre ...

Anonyme a dit…

merci et c'est bien dommage..
Bien souvent dans une appli on a besoin de rajouter des tables, des champs, des controles associés.
Pourquoi ne pas le prévoir dynamiquement dès le début?
On a deja ca dans le meta-modele en base de données par contre il n'y a pas d'extension aux couches métiers et présentation.
En fait, je reve d'avoir juste un moteur d'application me permettant d'avoir une gestion dynamique des tables-entités. Par exemple comme dans un meta-modèle mais élargi aux objets: CRUD sur les tables-entités et leurs définitions elles-memes, générer les méthodes et controles associés.
Bref qq chose de simple mais qui n'existe pas encore on dirait..