De nombreux articles ont été écrits sur le sujet des ORMs et de leurs limites. La majorité des objections se placent dans deux catégories : la séparation des préocupations (SoC) et le design orienté objet. Dans le cas d’Entity Framework nous avons de bonnes nouvelles concernant ces problématiques.
Séparation des Préocupations (SoC)
Les procédures stockées ne sont pas seulement un moyen de remplir la base de données de logique métier, c’est aussi un moyen d’éviter de remplir la couche applicative de logique de stockage. Cela permet à une application de voir une représentation idéalisée des données sans révéler les machinations du DBA. L’assortiment de tables de staging, de tables de reporting dénormalisées, de vues et de fonctions de table est caché derrière de simples appels de procédures qui représentent l’API publique de la base de données. Avec précaution, il est possible d’effectuer de l’amélioration mineure de performances ou un refactoring important sans avoir à redéployer les nombreuses applications qui dépendent de la base de données.
Dans les deux prochaines versions, Entity Framework a pour objectif de rendre plus facile l’utilisation des procédures stockées. Dans la version 5, qui est proche de la sortie définitive, nous voyons arriver les indispensables fonctions table et la possibilité d’importer en batch les procédures stockées. http://technet.microsoft.com/en-us/library/ms191165(SQL.105).aspx s’associent particulièrement bien avec les ORMs. Les fonctions table sont bien plus flexibles que les procédures stockées ou les vues, mais sans la génération SQL dynamique on ne peut réellement bénéficier de leurs avantages. Et la génération dynamique de SQL est la fonction clé qui sépare un ORM d’un classique data mapper. Malheureusement ceci est uniquement accessible au développeur utilisant les outils de modélisation. Si vous utilisez la technologie Code First d’Entity Framework vous devrez attendre http://blogs.msdn.com/b/wriju/archive/2012/07/19/entity-framework-5-and-6-roadmap.aspx pour disposer du support des procédures stockées, sans parler des fonctions table.
Design Orienté Objet
Le sujet du design orienté objet est complexe. Par nature les ORMs veulent de simples objets de transfert de données (DTO) avec des constructeurs par défaut et des propriétés publiques sur lesquelles l’ORM peut ajouter le lazy loading, le suivi des changements, ect… Mais les développeurs qui favorisent le design orienté objet préfèrent des objets riches avec des constructeurs complexes et une interface publique limitée. Les colonnes telles que CreatedBy ou CreatedDate doivent être représentées par des champs en lecture seule et des propriétés d’accès de telle sorte qu’il n’y ait aucune chance de modifier accidentellement leur valeur. Malheureusement, rien de tout cela n’arrivera prochainement. Vous pouvez toujours faire des choses avec les setters privés, mais en général les entités vont toujours plus ressembler à des DTOs qu’a de réels business objets. Sur le long terme, http://blogs.msdn.com/b/adonet/archive/2011/01/10/ef-feature-ctp5-pluggable-conventions.aspx. Cette fonctionnalité prometteuse était supposée faire partie d’Entity Framework 4.1, mais a été supprimée à cause de la complexité du design et du sentiment qu’elle n’était simplement pas prête. Sergey Barskiy a écrit http://dotnetspeak.com/index.php/2011/03/custom-conventions-in-entity-framework-code-first-v-4-1.