Discussion :

[MainMa]

J'ai une question d'ordre g�n�ral qui peut se r�sumer � "� quoi sert Entity Framework dans une application three-tier ?"

Je m'explique. � l'origine, on avait donc Linq to SQL, dont l'utilit� �tait de faire abstraction de la structure des donn�es SQL, � savoir ne plus avoir � �crire du SQL sous forme de chaines de caract�res pas v�rifi�es � la compilation, mais d'utiliser la base de donn�es sous une forme plus orient�e objet.

Maintenant, j'essaie de m'y mettre � Entity Framework (EF par la suite), qui, pour moi, non seulement reprenait de Linq l'id�e d'abstraction, mais ajoutait le caract�re orient� objet beaucoup plus pouss� (permettant d'organiser vraiment un ensemble de classes (ou entit�s) avec l'h�r�dit�, les discriminators, les classes abstraites, etc.
Du coup, en abordant la chose, j'ai cru (apr�s avoir vu des webcasts et les articles de Microsoft) qu'au final, �a pouvait remplacer la distinction entre business logic et le data access layer, autrement dit de me laisser indiquer � travers EF comment ma base de donn�es est li�e � BL, et laisser EF faire tout le travail.

Or, maintenant que j'ai un peu �tudi� EF, j'ai l'impression d'�tre compl�tement � cot� de la plaque. � lire Programming Entity Framework de J. Lerman, on y trouve des choses du type : "You can add business logic to the generated classes, pull the results into your own business objects, and even link your business objects to the EDM and remove the generated classes. But by definition, the entities describe only their schema."

Du coup la question : est-ce que si je cr�e une application lambda, bas�e tr�s fortement sur une base de donn�es, je dois cr�er mon BL directement dans EF, ou bien il ne faut pas m�langer les choses, mais cr�er d'un cot� mes BL/PL comme je faisais avant, et y ajouter par la suite le socle SQL via EF ?

[B.AF]

Du coup la question : est-ce que si je cr�e une application lambda, bas�e tr�s fortement sur une base de donn�es, je dois cr�er mon BL directement dans EF, ou bien il ne faut pas m�langer les choses, mais cr�er d'un cot� mes BL/PL comme je faisais avant, et y ajouter par la suite le socle SQL via EF ?

De toute fa�on propager des entit�s persistantes dans une application est une mauvaise id�e � la base.

Si tu te poses autant de question, c'est qu'il vaut mieux conserver une m�thode de conception qui fonctionne et ne pas construire toute une application sur des incertitudes.

La g�n�ration de code, c'est une bombe � retardement, l'utilisation intrusive d'un ORM aussi.

On se fout �perduement de s�parer "les objets m�tiers" des "objets bases de donn�e". Ce qui est important c'est que ce soit fiable, performant et maintenable. Surtout que dans pas mal de cas, les fameux objets m�tiers ne sont que des DTO an�miques reconstitu�s au co�t de milliers de lignes de recopie de propri�t�s.