Entity Framework, pour faire quoi ?

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 ?

Citation:

---

Envoyé par MainMa

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.