FluentNHibernate Unité de travail/Modèle de conception Repository Questions

Question

Je pense que je suis dans une impasse ici. J'ai une application que j'ai construite à partir de zéro en utilisant FluentNHibernate (ORM)/SQLite (fichier db). J'ai décidé de mettre en œuvre le modèle Unité de travail et conception de référentiel. Je suis à un point où je dois penser à la fin du jeu, qui va commencer comme une application Windows WPF (en utilisant MVVM) et éventuellement mettre en œuvre des services Web/ASP.Net comme interface utilisateur.

Maintenant, j'ai déjà créé des objets de domaine (entités) pour ORM. Et maintenant je ne sais pas comment l'utiliser en dehors d'ORM. Les questions à ce sujet sont les suivantes:

• Dois-je utiliser des objets entité ORM directement comme modèles dans MVVM? Si oui, est-ce que je mets une logique métier (telle que certaines valeurs doivent être positives et supérieures à une autre propriété) dans ces objets entité? C'est certainement l'approche la plus simple, et je suis en train de pencher en ce moment. Cependant, y aura-t-il des pièges qui feraient échouer ce plan?
• Si la réponse ci-dessus est non, puis-je créer un nouvel ensemble de classes pour implémenter la logique métier et les utiliser comme modèles dans MVVM? Comment traiterais-je la transition entre les objets du modèle et les objets d'entité? Je suppose qu'une implémentation de convertisseur de type fonctionnerait bien ici.

Answer 1

Pour répondre à la première partie de votre question, oui votre logique métier et la validation devraient aller dans vos entités. Le but de NHibernate est de vous permettre de concevoir vos entités comme étant ignorantes de la persistance. Cela signifie que vous devriez, dans la mesure du possible, concevoir vos entités comme vous le feriez si vous ne vous souciez pas de la persistance. Ce n'est pas tout à fait faisable car vous le découvrirez bientôt (vous aurez besoin de rendre vos propriétés virtuelles afin de supporter le chargement paresseux et si vous voulez utiliser NHibernate Validator, vous décorerez vos propriétés avec des attributs de validation), mais pour la plupart NHibernate fait un bon travail de rester hors de votre chemin. En ce qui concerne l'utilisation de vos entités en tant que modèles, vous obtiendrez des avis mitigés à ce sujet. Idéalement, vous créez des classes viewmodel séparées et vous mappez de vos entités au viewmodel afin que vos vues accèdent uniquement au strict minimum d'informations dont elles ont besoin. Cela va aussi un long chemin en empêchant N+1 access issues. Cependant, le faire est souvent une énorme douleur. Certes, il existe des outils tels que AutoMapper qui faciliteront la transposition de vos propriétés d'entité en un modèle de vue.