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 ?
Partager