Rendre OR/M lâchement couplé et séparé des autres couches

Question

Dans une architecture à plusieurs niveaux, le meilleur endroit pour placer un code de mappage relationnel objet (OR/M) est dans la couche d'accès aux données. Par exemple, les requêtes de base de données et les mises à jour peuvent être déléguées à un outil comme NHibernate. Cependant, je voudrais garder toutes les références à NHibernate dans la couche d'accès aux données et les dépendances abstraites loin des couches au-dessous ou au-dessus. De cette façon, je peux échanger ou connecter un autre outil OR/M (par exemple Entity Framework) ou une approche (par exemple, des appels de procédures stockées plain vanilla, des objets simulés) sans provoquer d'erreurs de compilation ou de révision majeure de l'application entière. La testabilité est un bonus supplémentaire.

Est-ce que quelqu'un pourrait suggérer un emballage (c'est-à-dire une interface ou une classe de base) ou une approche qui permettrait de maintenir un couplage lâche ou non et d'être contenu dans une couche? Ou me diriger vers des ressources qui pourraient aider?

Merci.

Answer 1

Il semble que vous cherchiez le modèle repository. Si vous avez besoin de plus de découplage, vous pouvez injecter les dépendances de données avec un conteneur Inversion of Control.

Answer 2

Service Facade Pattern est un nom. Contrats simples entre la logique métier et la couche de données.

Les classes de service ou les beans (appelez-le comme vous voulez) définissent et implémentent le contrat et orchestrent la couche de données inférieure, en gérant souvent la logique transactionnelle à travers les objets de données.

Dans Spring, vous définissez une interface, puis l'implémentez. Une implémentation peut être un OR/M, une autre peut être brute JDBC ou ADO.NET. Dans certains cadres, la programmation orientée aspect vous permet d'injecter une logique transactionnelle déclarative sans écrire de code. Cela économise beaucoup de maux de tête. Une mise en garde: Lorsque vous traitez des OR/Ms comme Hibernate, il y a l'utilisation de classes proxy. Cela pollue les choses, car il existe quelques cas où les classes de proxy causent des problèmes. À mon avis, c'est un détail d'implémentation qui ne devrait pas échapper à la couche de service. Mais avec Hibernate, c'est le cas. Je ne suis pas sûr de l'implémentation de .NET.