L'architecture pilotée par les modèles est-elle compatible avec LINQ-to-SQL ou Entity Framework?

Question

Mon système nouvellement créé a été créé en utilisant l'approche Model Driven Architecture donc tout ce que j'ai est le modèle (disons des classes complètes 'Order' et 'Product'). Ce sont des classes entièrement testées qui supportent l'activité de mon application. Maintenant, il est temps de persister ces classes en tant qu'objets sur le disque dur et, plus tard, de les récupérer dans le même état (en pensant très abstraitement ici). Généralement, je créerais une interface IOrderRepository et éventuellement une classe OrderRepository pilotée par ADO.NET avec des méthodes telles que GetAll(), GetById(), Save(), etc ... ou à un moment donné une classe OrderRepostiroy pilotée par BinaryFormatter un but similaire à travers cette même interface commune. Cette approche ne convient-elle pas à LINQ-To-Sql ou à Entity Framework.? Quelque chose qui tente de construire mon modèle à partir d'une structure de base de données préexistante me semble incorrect. Pourrais-je tirer parti de ces technologies tout en conservant cette approche «MDA» de l'ingénierie logicielle?

... remarque Je n'ai pas mentionné qu'il s'agissait d'une application Web. Cela peut être ou ne pas être - et ne devrait pas avoir d'importance.

Answer 1

En général, je pense que vous ne devriez pas faire de types mettant en œuvre des méthodes et types d'affaires utilisés pour le mappage O/R du même type. Je pense que cela viole le principe de la responsabilité unique. Le point de vos types d'entités est de combler le fossé entre l'espace relationnel et l'espace objet. Le point de vos types d'entreprise est d'avoir des collections de comportement testable. Au lieu de cela, je suggérerais que vous projetiez de vos types d'entité sur vos types d'entreprise lors de la matérialisation des objets de la base de données. Séparer ces deux méthodes permet aux méthodes métier et aux mappages de données d'évoluer indépendamment, ce qui est très important, surtout si vous ne pouvez pas toujours contrôler le schéma de la base de données. J'explique plus complètement cette idée in this presentation.