Release d'EntityFramework.Patterns

Publié par Fabrice Michellonet sous le(s) label(s) le 7 juillet 2011

Bon ça y est je me suis décidé à trouver un toit pour EntityFramework.Patterns, une librairie qui s'adossant à Entity Framework 4.1, propose l'implémentation de patterns couramment nécessaire lorsqu'on utilise un ORM.

Je n'ai toujours pas cédé aux appels des sirènes de Github; EntityFramework.Patterns est donc hébergé sur Codeplex. Vous trouverez également la librairie sur nuget... d'ailleurs elle y était présente bien avant la création du repository sur codeplex.

Pour l'installer via nuget, rien de plus simple :

install-package EntityFramework.Patterns

A l'heure actuelle, vous trouverez deux patterns d'infrastructure :

  • Repository
  • Unit Of work
Rob Conery les définissaient ainsi récemment :
The Repository Pattern is all about encapsulating calls to your DB as methods to do a thing. These calls are (typically) atomic.

Tout est dit! L'avantage est simple, couplé avec un/des décorateurs il sera facile d'ajouter des comportements transverses (cache, securité, log etc...)
UnitOfWork is - well it’s a way of transactionally flushing changes to a persistence store (aka Database)

Ce qui permet de découpler facilement la gestion d'état des entités et le requêtage.

Des patterns d'infrastructure pour l'instant, qui seront rapidement suivit par les patterns suivants :

  • Repository Decorator
  • Audit log
  • Audit trail
  • Archived entity
  • Internationalized entity

Dans un tout prochain post je présenterais ces deux patterns Repostitory<T> et UnitOfWork.

6 commentaires:

riadh a dit… @ 13 août 2012 à 11:56

Bravo Fabrice,
Je suis entrain de l'utiliser dans un gros projet, un site web a forte audience.
Je n'ai qu'un seul probléme a résoudre c'est centraliser le code des lambda dans des predicates.

merci bien
Riadh

FabriceMICHELLONET a dit… @ 20 août 2012 à 00:10

Bonjour riadh,

tu peux tout à fait centraliser tes lambda comme une simple variable.
Par exemple tu peux en déclarer une ainsi :

Expression> _myPredicate = u => u.id == id && u.status == status;

puis l'utiliser avec ton repository :

userRepo.Find(_myPredicate);

J'espère que cela te convient et merci d'utiliser EntityFramework.Patterns sur ton projet.

riadh a dit… @ 20 août 2012 à 00:18

Merci Fabrice pour ta réponse.
Maintenant me manque plus qu'un tuto comment faire des test unitaires, tu as dit que t'allait faire un post dessus mais j'arrive pas a le trouver (Di avec ninject si possible)
Bravo encore
Riadh

riadh a dit… @ 20 août 2012 à 00:19

Aussi j'ai peut etre trouvé un bug ou .Find() prends deux fois plus de temps que AsQueryable().where()
Je n'en suis pas encore sur manque de temps pour confirmer sur un projet de test.
Je te tiens au courant

FabriceMICHELLONET a dit… @ 23 août 2012 à 23:19

Désole de ne pas avoir répondu dans la foulée l'autre soir... tu me croiras ou non mais la carte mère de mon portable à lâchée... trop chaud surement!

Pour en revenir à l'injection de dépendances, je n'ai finalement pas posté d'article ici car j'ai documenté cette notion sur le site codeplex ici : http://efpatterns.codeplex.com/wikipage?title=IoC%20%3a%20Unity%202.1&referringTitle=Documentation

Dans cet exemple je n'utilise pas NInject mais Unity. Cependant le principe est le même.

Finalement, tu peux également jeter un œil sur un exemple d'architecture MVC découplé utilisant entre autres NInject et EntityFramework.Pattern et que j'ai publié ici : https://github.com/fmichellonet/MVCArch.

J'espère que cela t'aidera.

FabriceMICHELLONET a dit… @ 23 août 2012 à 23:20

Si tu as un projet de test, je suis preneur.

Enregistrer un commentaire