Comment dois-je gérer mes objets entité/domaine en utilisant IoC/Dependency Injection?

Question

J'utilise actuellement PLINQO pour générer toutes mes entités de la base de données. Récemment, j'ai commencé à utiliser l'injection de dépendances en utilisant StructureMap, et dans le cadre du processus d'apprentissage de «séparer mes préoccupations». J'ai remarqué que toutes les classes Entity générées contiennent des propriétés hautement couplées en utilisant EntitySet, une partie de LINQ, ce qui rend mes entités dépendantes de l'utilisation de System.Data.Linq. Je voudrais continuer à utiliser mes entités générées par PLINQO, mais en même temps, je pense que je devrais probablement générer des objets de classes de base/données seulement, et peut-être même les déplacer dans un autre assembly, puis utiliser une sorte de mappeur automatique pour convertir entre les deux, selon les besoins. Au mieux (ou pire, selon la façon dont vous le regardez), j'aimerais que certaines interfaces les représentent, afin que je puisse les injecter avec différents types de béton plus tard.

Est-ce une surpêche? Finalement, je vais passer de l'utilisation de SQL Server directement à l'utilisation des services Web, et je doute que ces EntitySets passeront par-dessus le fil aussi facilement.

Est-ce que quelqu'un a de bons exemples de travail avec un scénario comme celui-ci?

TIA

Answer 1

Je pense que vous êtes sur la bonne voie - ne laissez pas le nom des classes L2S générés vous tromper. Ils ne sont pas des Entités dans la terminologie DDD, mais simplement des représentations fortement typées de la base de données. Si vous me demandez, c'est un détail d'implémentation qui ne devrait pas être autorisé à envahir le Couche de domaine. Avec le framework .NET currett, et si vous restez purement avec le BCL et n'utilisez pas de bibliothèques supplémentaires, votre seule option est de définir des Entités persistantes-ignorantes dans votre Modèle de Domaine puis de les mapper aux classes L2S dans les données. couche d'accès. C'est une douleur, mais AutoMapper peut être utile à cet égard. Si vous êtes prêt à dévier un peu de la BCL pure, il existe des bibliothèques Open Source qui offrent une ignorance de la persistance, comme NHibernate - Je n'ai aucune expérience personnelle avec NHibernate, mais beaucoup de gens intelligents pensent hautement de il.

Dans .NET 4.0, Entity Framework, et par conséquent LINQ to Entities will also offer persistence ignorance. Jeremy Miller a un article in MSDN Magazine that somewhat touches upon the subject.