Aide avec / DDD, SOA et PI

Question

Sans entrer dans tous les détails sanglants, j'essaie de concevoir une solution basée sur les services qui sera utilisée par plusieurs applications clientes. La solution permet aux administrateurs de créer et de modifier des modèles de documents qui sont utilisés par les utilisateurs réguliers pour effectuer la saisie de données. J'ai l'intention de faire de l'application un outil d'apprentissage des meilleures pratiques, techniques, etc.

Et, en même temps, je dois m'adapter à un environnement schizophrène parce que les «pouvoirs en place» ne peuvent jamais s'en tenir à leurs décisions concernant les technologies et les outils. Par exemple, j'utilise Linq-to-SQL aujourd'hui car ils ne sont pas prêts à passer à EF4, mais il y a aussi des discussions sur le passage à NHibernate. Donc, je dois rendre le code aussi ignorant que possible pour minimiser le travail requis si nous changeons les outils OR / M.

À ce stade, je suis également limité à l'utilisation de l'approche de classe partielle pour étendre les classes Linq-to-SQL afin qu'elles implémentent les interfaces définies dans ma couche métier. Je ne peux pas accepter les POCO parce que la direction insiste pour que nous tirions parti de tous les outils intégrés, etc. donc je dois prendre en charge le concepteur Linq-to-SQL.

Cela dit, mon interface de service a une méthode StartSession qui accepte un identifiant de modèle dans sa signature. L'opération se déroule comme suit:

1. Si une session existe déjà dans la base de données pour l'utilisateur actuel et le modèle spécifié, mettez à jour l'enregistrement pour afficher l'activité en cours. Sinon, créez un nouvel objet de session.
   
2. La session est associée à une instance du modèle, appelez-la le "formulaire". Donc, si la session est nouvelle, je dois récupérer les informations du modèle pour créer le nouveau "formulaire", l'associer à la session puis enregistrer la session dans la base de données. En revanche, si la session existait déjà, je dois également charger le "formulaire" avec les données saisies par l'utilisateur et stockées dans la session précédemment.
   
3. Enfin, la session (avec la définition du formulaire et les données) est renvoyée à l'appelant.
   

Mon premier objectif est de créer une séparation nette entre les couches logiques de mon application. Le second est de maintenir l'ignorance de la persistance (comme mentionné ci-dessus). Troisièmement, je dois être capable de tout tester, donc toutes les dépendances doivent être externalisées pour faciliter les moqueries. J'utilise Unity comme outil IoC pour m'aider dans ce domaine.

Pour ce faire, j'ai défini ma classe de service et mes contrats de données selon les besoins pour prendre en charge l'interface de service. La classe de service aura une dépendance injectée à partir de la couche de gestion qui effectue réellement le travail. Et c'est là que ça a été compliqué pour moi.

J'ai essayé de suivre la route de l'Unité de travail et du référentiel pour aider à l'ignorance de la persistance. J'ai un ITemplateRepository et un ISessionRepository auxquels je peux accéder depuis mon implémentation IUnitOfWork. La classe de service obtient une instance de ma classe SessionManager (dans mon BLL) injectée. Le SessionManager reçoit l'implémentation IUnitOfWork via l'injection du constructeur et déléguera toute la persistance à l'UoW mais je me retrouve à jouer à un jeu shell avec les différentes logiques.

Toute la logique décrite ci-dessus devrait-elle être dans la classe SessionManager ou peut-être dans l'implémentation UoW? Je veux aussi peu de logique que possible dans les implémentations du référentiel, car la modification de la plate-forme d'accès aux données pourrait entraîner des modifications indésirables de la logique de l'application. Étant donné que mon référentiel fonctionne sur une interface, comment puis-je créer au mieux la nouvelle session (en gardant à l'esprit qu'une session valide a une référence au modèle, euh, au formulaire utilisé)? Serait-il préférable de continuer à utiliser les POCO même si je dois supporter le concepteur et utiliser un outil comme AutoMapper dans l'implémentation du référentiel pour gérer la traduction des objets?

Ugh!

Je sais que je suis juste coincé dans la paralysie de l'analyse, donc un petit coup de pouce est probablement tout ce dont j'ai besoin. Quel serait l'idéal serait b

e si quelqu'un pouvait donner un exemple de la manière dont vous résoudriez le problème compte tenu des règles métier et des contraintes architecturales que j'ai définies.

Answer 1

Si vous n'utilisez pas de POCO, vous ne serez pas vraiment indépendant du magasin de données.Et l'utilisation des POCO vous permettra de faire fonctionner votre système avec des référentiels basés sur la mémoire, ce que vous voudrez probablement utiliser de toute façon pour vos tests unitaires.

L'AutoMapper sonne bien mais je ne le considérerais pas comme un facteur décisif.Le mappage des POCO à EF4, LinqToSql, nHibernate ne prend pas beaucoup de temps à moins que vous n'ayez des centaines de tables.Quand / si vos POCO commencent à diverger de votre couche de persistance, vous constaterez peut-être qu'un AutoMapper ne fera pas vraiment l'affaire.