Spécification Motif défini dans le domaine

Question

En utilisant Linq to SQL et une couche de domaine de style DDD avec des référentiels découplés, quelqu'un a-t-il de bonnes idées sur la façon d'implémenter un specification pattern sans soulever des problèmes L2S dans la couche domaine, c'est-à-dire compréhensible? :)

Nous avons une logique métier complexe entourant la sélection d'un ensemble de données de transaction, et souhaitons que ces règles/spécifications soient la propriété du domaine. Nous avons également fait du bon travail pour garder notre persistance de domaine ignorant.

Cela présente un problème, car pour implémenter une spécification, le domaine (pour autant que je sache) a besoin de voir les types interrogés (types L2S).

Des idées?

En outre, NHibernate est hors de question, pour des raisons que je ne veux pas expliquer .. :)

Answer 1

LINQ to Sql classes peuvent être partielles. Cela signifie que vous pouvez les étendre en implémentant un partial qui implémente une interface commune. Cette interface peut être partagée entre les couches sans le problème de "saignement" que vous décrivez. Le reste est juste les détails de votre "IsStatisfiedBy" qui devrait être facile à encapsuler.

Answer 2

J'ai récemment eu le même problème. Modèle différent, mais toujours LINQ to SQL (L2S). J'ai essayé deux manières différentes d'éviter la fuite.

Nous avons d'abord essayé d'utiliser des DTO et une couche de mappage. Nous avons donc écrit des objets super simples avec un mappage un à un vers les tables. Ils étaient tous décorés avec des attributs L2S. Nous avons ensuite écrit une couche de mappage pour mapper les objets DTO à nos objets métier. Tout cela a été caché via le modèle Repository de Doman Driven Design. Donc, les consommateurs des objets d'affaires ne savaient pas que le L2S était sous le capot.

Ensuite, surtout pour la variété. Nous avons essayé d'utiliser les fonctions de mappage XML de L2S afin que les objets eux-mêmes n'aient pas besoin d'attributs. Pour les collections, nous avons exposé IEnumerable au lieu de l'une des collections L2S. Si vous avez examiné les composants internes des classes métier, vous pouvez toujours détecter une utilisation de L2S (EntitySet ou Ref). Mais les consommateurs de la classe n'avaient aucune idée. Donc quelques morceaux de fuite mais rien de radical. En fin de compte, nous avons suivi le premier modèle. La seconde fonctionnait et nous aurions pu remplacer L2S sans changer l'interface de la couche de gestion, mais je n'ai jamais été satisfait du mapping XML. Le premier modèle avait une séparation beaucoup plus propre entre la base de données et les objets métier. Il a fallu plus de code. Le premier a également fonctionné mieux pour nous car il nous a permis de faire évoluer les objets métier différemment des tables. Dans les premiers jours du projet, le mappage xml a fonctionné parce que nos objets étaient presque un à un avec les tables. Donc, à la fin, nous avons mis une couche entre L2S et le domaine. Ça a marché. Il a fallu plus de code, mais c'était vraiment simple. Et tout était très testable.

Answer 3

Si vous voulez éviter de référencer Linq2Sql à partir de votre couche de domaine, vous devez travailler avec des interfaces qui représentent vos entités au lieu de travailler avec les entités elles-mêmes. Vous avez ensuite besoin d'une couche de mappage entre vos interfaces et vos entités. J'ai travaillé de cette façon et j'ai trouvé que c'était un obstacle sérieux. Je suis passé à NHibernate pour de nouveaux projets et pour les projets plus anciens, j'ai simplement arrêté de m'inquiéter du domaine référençant directement les entités Linq2Sql. Surmonter cette restriction est simplement trop de temps-coût à mon avis.

Answer 4

Avez-vous envisagé de mettre en correspondance vos spécifications génériques dans un arbre Expression qui se traduirait par la syntaxe L2S appropriée? Il semble que c'est le principal problème que vous rencontrez ici. Le modèle de spécification n'est pas le problème, mais le mappage à L2S est.