Les objets Business Logic doivent-ils connaître leurs objets de données LINQ-to-SQL?

Question

J'ai examiné plusieurs questions similaires mais je n'en ai pas vu de celles qui me concernaient directement, alors pardonnez-moi s'il s'agit d'un doublon.

Pour dissocier les préoccupations, j'essaie de mapper d'une manière ou d'une autre mes objets métier avec une logique vers les objets de données LINQ to SQL dans le fichier .dbml (relativement nouveau dans ce btw). Toutefois, l’objet de cette opération est que mes objets métier vont avoir besoin de connaître les objets LINQ2SQL correspondants. Je lis cet article sur l'utilisation de fichiers POCO avec un fichier de mappage xml, et il semble que cela ressemble à ce que je veux, sauf que je n'ai pas de mappage un à un entre les tables et les classes à cause d'une relation plusieurs-à-plusieurs pour laquelle j'avais besoin de créer une table supplémentaire.

Je peux très bien encapsuler l'accès aux données dans ma logique métier, de sorte que le code qui utilise mes objets métier n'a pas besoin de savoir quoi que ce soit sur la base de données, mais que la couche de gestion est toujours étroitement liée à l'accès aux données. couche de sorte que je ne puisse pas échanger le DAL sans changer mes objets de couche de gestion ou en créer de nouveaux (qui implémentent les mêmes interfaces) pour différents fournisseurs de données.

Comment puis-je découpler ces couches?

Answer 1

Vous ne savez pas vraiment si vous êtes lié à LINQ to SQL, mais ce que vous essayez d'accomplir est à peu près le résultat par défaut de NHibernate. Je recommande d’examiner NHibernate pour savoir s’il serait plus facile de passer à autre chose que de combattre LINQ en SQL.

J'ai constaté que lutter contre un outil est presque toujours une mauvaise idée.