Comment puis-je résoudre cette requête NHibernate dans une architecture n-tier?

J’ai tenté de découpler NHibernate de ma couche de services. Mon architecture ressemble à ceci:

web -> services -> référentiels -> nhibernate -> db

Je veux être en mesure de générer des requêtes sans ressortingction à partir de ma couche de services et éventuellement de ma couche Web sans que ces couches sachent à quoi elles sont confrontées. Actuellement, j’ai une méthode de recherche sur tous mes référentiels qui prend en compte les IList criteria . Cela me permet de transmettre une liste de critères tels que new object() {"Username", usernameVariable}; de n’importe où dans mon architecture. NHibernate en tient compte, crée un nouvel object Critères et ajoute les critères entrés. Cela fonctionne bien pour les recherches de base de ma couche de service, mais j’aimerais pouvoir transmettre un object de requête que mon référentiel traduit en critère NHibernate.

Vraiment, j’aimerais implémenter quelque chose comme ce qui est décrit dans cette question: Y a – t-il avantage à faire abstraction du critère nhibernate . Je ne trouve tout simplement pas de bonnes ressources sur la façon de mettre en œuvre quelque chose comme ça. La méthode décrite dans cette question est-elle une bonne approche? Dans l’affirmative, quelqu’un pourrait-il donner des indications sur la manière de mettre en œuvre une telle solution?

extraire l’ORM:

apporter beaucoup de travail de redéfinition de son API
rendre impossible l’optimisation / l’access par lots à la firebase database
il est beaucoup plus difficile de comprendre quelles requêtes sont exécutées
conduira à des tonnes de SELECT N + 1

et le tout pour très peu de valeur: l’option vague d’échanger le cadre ORM qui aura probablement beaucoup d’autres problèmes

caractéristiques manquantes
différence subtile dans la mise en œuvre
courbe d’apprentissage

Mise à jour: expérience

J’ai déjà été impliqué dans la mise en place d’un nouveau fournisseur d’abstraction DAL existante. Il a fini par mal fonctionner, a introduit beaucoup de bugs, Errorhandling était un gâchis et utilisait parfois des données obsolètes parce que l’application assumait l’implémentation par défaut. Les raisons:

La mise en cache ne sait pas le contexte
La cacheimlementation avait une sémantique différente
Les API de traitement par lots sont trop différentes pour pouvoir être extraites
Les erreurs sont spécifiques à la mise en oeuvre (par exemple, FileNotFound -> FilesearchDialog est inutile pour une firebase database basée sur TCP / IP)
La récupération sur erreur est différente (chaque implémentation a son propre ensemble d’erreurs qu’elle peut récupérer)
mécanisme de locking était différent
pas d’événement de changement cohérent dans SQL-Databases
transactions nestedes
implémentation par défaut saignée dans les classes de modèle
réimplémenter toutes les requêtes abstraites demandait beaucoup de travail et introduisait beaucoup de bugs de copier-coller
interroger sans indiquer explicitement que l’ordre retournera différents résultats ordonnés dans différentes implémentations

Il a fallu beaucoup de refactoring de l’application:

supprimer les fonctionnalités que seule une mise en œuvre fournit
Cachemanagement pour chaque implémentation
problème d’identité des emballeurs à cause de données transitoires
implémenter très dur les requêtes sur deux datastores

Points supplémentaires:

La migration des données à travers l’abrégé DAL est lente comme l’enfer
la mise en œuvre d’une autre implémentation ne se produira jamais à cause des problèmes mentionnés ci-dessus, elle est trop chère (dans le scénario mentionné, nous avons commencé à réimplémenter lentement l’ensemble du projet)
il était extrêmement difficile d’implémenter la sémantique correcte de l’API DAL car il n’y a pas de contexte d’utilisation dans l’API pure

Le portage (des tâches de l’entreprise) aurait été beaucoup moins pénible à l’OMI car nous l’avons fait pour quelques-uns à cause des performances.

Update2: experience2: RoadBlocks lors de la tentative de transfert de NHibernate à EntityFramework (impl avec NH mais pas avec EF 4 dans un délai raisonnable)

Transactions nestedes
Enum support
références avec compositeId (comment se débarrasser de referenceIds)
références en composants
lire le traitement par lots (Futures), ce qui est pratique pour compter + page en une fois
mappage CultureInfo (prise en charge de IUserType)

Merci pour les réponses! Je comprends ce que vous dites, mais ces réponses ne résolvent pas mon problème. En raison de l’état du système que j’écris, je ne peux pas changer d’architecture. Au lieu de cela, je vais simplement conserver toutes mes requêtes d’API SQL / HQL / Critères à l’intérieur de la couche de référentiel au lieu d’essayer d’exposer une sorte de classe de requête complexe à mes services. Cette approche devrait fonctionner correctement. Pour ma prochaine approche architecturale cependant, je considérerai les points soulevés dans les autres réponses.