modèle de référentiel avec une base de données existante et Linq to SQL

Question

Je construis une application sur une base de données existante (que je ne peux pas modifier). J'utilise Linq to SQL pour l'accès aux données, ce qui signifie que j'ai une classe (Linq to SQL) pour chaque table.

Mon modèle de domaine ne correspond pas à la base de données. Par exemple, il existe deux tables nommées Utilisateurs et Employés . Par conséquent, j'ai deux classes Linq to SQL nommées Utilisateur et Employé <. / code>. Mais dans mon modèle de domaine, j'aimerais une classe User qui devrait contenir des champs de l'une ou l'autre table (mais je me fiche de beaucoup d'autres champs de ces tables).

Je ne sais pas comment concevoir mes référentiels:

• les référentiels doivent-ils effectuer le mappage entre les classes Linq et SQL (par exemple, Utilisateur , Employé ) avec les classes de domaine ( Utilisateur ) et uniquement renvoie les classes de domaine à l'application
• ou mes référentiels doivent renvoyer les classes Linq to SQL et laisser le mappage à l'appelant

La première approche me semble plus logique, mais est-ce la bonne façon de mettre en œuvre mes référentiels?

Answer 1

Le puriste (j'essaie de rester pur) vous dira que votre modèle représente vos données. Et par conséquent, tout ce qui doit être persisté ne l’est fait que lorsque cela est nécessaire par le biais de dépôts. De même, lorsque vous avez des entités complexes, vous souhaitez utiliser un service pour les combiner. Par exemple, entité Utilisateur + Employé = UtilisateurEmployé accessible uniquement par le biais d'un IUserEmployeeService.

Avec ces déclarations vagues, vous avez ici une excellente opportunité.

Construisez une couche anti-corruption, qui vous permet de commencer à quitter simultanément la base de données existante.

Ceci est un autre chapitre du livre de lecture DDD. Une couche anti-corruption est utilisée pour l’interface avec un système existant utilisant des façades, des traducteurs et des adaptateurs afin d’isoler la base de données existante avec votre modèle de domaine pur.

Maintenant, cela peut être beaucoup plus de travail que vous ne le souhaitiez. Donc, vous devez vous demander à ce stade:

  

Est-ce que je veux commencer le processus de   sortir de cette base de données héritée, ou sera   il reste pour la vie du   application?

Si votre réponse est que vous pouvez commencer à migrer, modélisez votre domaine réel comme vous le souhaitez. Conservez-le avec des référentiels et des services normaux. Amusez-vous à le concevoir comme VOUS le souhaitez. Ensuite, utilisez les services des racines agrégées pour accéder à la couche anti-corruption et extrayez les entités, stockez-les / mettez-les à jour localement et traduisez-les en entités de votre domaine.

Si la réponse est que l'ancienne base de données restera en place pendant toute la durée du projet, votre tâche est beaucoup plus facile. Utilisez les services de votre domaine (par exemple, UserEmployeeService) pour accéder à UserFacade et EmployeeFacade de l'anti-corruption (similaire à un concept de "service distant").

Dans les façades, accédez à la base de données héritée à l’aide des adaptateurs (par exemple, LegacyDbSqlDatabase) pour obtenir un legacyUser () brut. L'étape suivante consiste à utiliser un mappeur UserTranslator () et EmployeeTranslator () qui convertit les données d'utilisateur héritées en version de votre domaine de l'entité User () de votre domaine réel, puis à les renvoyer de UserFacade à votre UserEmployeeService, où elles sont combinées avec l'entité Employé venant du même endroit.

Whoa, c’était beaucoup de dactylographie ...

Avec vos adaptateurs et façades de votre couche anti-corruption, vous pouvez effectuer votre Linq-to-Sql ou ce que vous voulez. Cela n'a pas d'importance, car vous avez complètement isolé le système / base de données hérité de votre domaine pur et pur - votre domaine qui possède sa propre version d'entités User () et Employee () et d'objets de valeur.

Answer 2

DDD et Linq To SQL ne vont pas très bien ensemble car les classes générées ne doivent pas s'écarter de manière significative de la structure de votre table de base de données. Vous devrez mapper vos classes de manière à rendre le travail avec Linq to SQL difficile ou simplement vivre avec un modèle objet non idéal.

Si vous voulez vraiment utiliser DDD et que le modèle de référentiel opte pour Entity Framework ou encore mieux pour NHibernate.