Accès aux données dans le code, à l'aide de référentiels, même avec des ORM

Introduction

Dans le monde .NET, l'une des méthodes les plus utilisées pour accéder aux bases de données consiste à utiliser Entity Framework (EF), un mappeur relationnel objet (ORM) étroitement intégré à la syntaxe du langage. Grâce aux requêtes Language Integrated Queries (LINQ) natives des langages .NET, l'accès aux données donne l'impression de travailler avec des collections .NET normales, sans grande connaissance de SQL. Cela a ses avantages et ses inconvénients sur lesquels je vais essayer de ne pas parler ici. Mais l'un des problèmes que cela crée constamment est la confusion concernant la structure du projet logiciel, les niveaux d'abstraction et finalement les tests unitaires.

Cet article tentera d'expliquer pourquoi l'abstraction du référentiel est TOUJOURS utile. Notez que de nombreuses personnes utilisent le référentiel comme terme désignant l'accès aux données abstraites, alors qu'il existe également un modèle de logiciel de référentiel qui concerne des choses similaires, mais ce n'est pas la même chose. Ici, j'appellerai un référentiel une série d'interfaces résumant les détails d'implémentation de l'accès aux données et ignorerai complètement le modèle de conception.

Histoire

N'hésitez pas à ignorer ceci si vous en êtes conscient, mais je dois d'abord expliquer comment nous sommes arrivés à l'idée des référentiels pour commencer.

Dans la préhistoire, le code était simplement écrit tel quel, sans structure, avec tout, faisant ce que vous vouliez qu'il fasse ou du moins espériez le faire. Il n’y a pas eu de tests automatisés, juste du piratage et des tests manuels jusqu’à ce que cela fonctionne. Chaque application a été écrite avec tout ce qui était disponible, les préoccupations concernant les exigences matérielles étant plus importantes que la structure du code, la réutilisation ou la lisibilité. C'est ce qui a tué les dinosaures ! Fait vrai.

Lentement, des modèles ont commencé à émerger. Pour les applications métiers en particulier, il y avait cette séparation évidente entre le code métier, la persistance des données et l’interface utilisateur. Celles-ci furent appelées couches et furent bientôt séparées en différents projets, non seulement parce qu'ils couvraient des préoccupations différentes, mais aussi parce que les compétences nécessaires pour les construire étaient particulièrement différentes. La conception de l'interface utilisateur est très différente du travail de logique de code et très différente de SQL ou de tout autre langage ou système utilisé pour conserver les données.

Par conséquent, l'interaction entre l'entreprise et la couche de données s'est faite en la abstrait dans des interfaces et des modèles. En tant que classe affaires, vous ne demanderiez pas la liste des entrées dans un tableau, vous auriez besoin d'une liste filtrée d'objets complexes. Il serait de la responsabilité de la couche de données d'accéder à tout ce qui est conservé et de le mapper à quelque chose de compréhensible pour l'entreprise. Ces abstractions ont commencé à être appelées référentiels.

Sur les couches inférieures d'accès aux données, des modèles comme CRUD ont rapidement pris le dessus : vous définissiez des conteneurs de persistance structurés comme des tables et vous créiez, lisiez, mettiez à jour ou supprimiez des enregistrements. Dans le code, ce type de logique sera résumé dans des collections, comme une liste, un dictionnaire ou un tableau. Il y avait donc aussi un courant d'opinion selon lequel les référentiels devraient se comporter comme des collections, peut-être même être suffisamment génériques pour ne pas avoir d'autres méthodes que la création, la lecture, la mise à jour et la suppression proprement dites.

Cependant, je suis fortement en désaccord. En tant qu'abstractions de l'accès aux données par l'entreprise, elles doivent être aussi éloignées que possible des modèles d'accès aux données, mais plutôt modélisées en fonction des exigences de l'entreprise. C'est ici que l'état d'esprit d'Entity Framework en particulier, mais de nombreux autres ORM, a commencé à entrer en conflit avec l'idée originale du référentiel, culminant avec des appels à ne jamais utiliser de référentiels avec EF, qualifiant cela d'anti-modèle.

Plus de couches

Beaucoup de confusion est générée par les relations parent-enfant entre les modèles. Comme une entité de département contenant des personnes. Un référentiel de service doit-il renvoyer un modèle contenant des personnes ? Peut-être pas. Alors que diriez-vous de séparer les référentiels en départements (sans personnes) et en personnes, puis d'avoir une abstraction distincte à mapper ensuite aux modèles commerciaux ?

La confusion augmente en fait lorsque nous prenons la couche métier et la séparons en sous-couches. Par exemple, ce que la plupart des gens appellent un service métier est une abstraction consistant à appliquer une logique métier spécifique uniquement à un type spécifique de modèle commercial. Supposons que votre application fonctionne avec des personnes. Vous disposez donc d'un modèle appelé Personne. La classe chargée de gérer les personnes sera un PeopleService, qui obtiendra les modèles commerciaux de la couche de persistance via un PeopleRepository, mais fera également d'autres choses, notamment un mappage entre les modèles de données et les modèles commerciaux ou un travail spécifique lié uniquement aux personnes, comme calculer leur salaires. Cependant, la plupart des logiques métier utilisent plusieurs types de modèles, de sorte que les services finissent par être des wrappers de mappage sur des référentiels, avec peu de responsabilités supplémentaires.

Imaginez maintenant que vous utilisez EF pour accéder aux données. Vous devez déjà déclarer une classe DbContext contenant des collections d'entités que vous mappez aux tables SQL. Vous disposez de LINQ pour les parcourir, les filtrer et les mapper, qui sont efficacement convertis en commandes SQL en arrière-plan et vous donnent ce dont vous avez besoin, avec des structures hiérarchiques parent-enfant. Cette conversion prend également en charge le mappage des types de données internes à l'entreprise, comme des énumérations spécifiques ou des structures de données étranges. Alors pourquoi auriez-vous même besoin de référentiels, peut-être même de services ?

Je crois que même si davantage de couches d'abstraction peuvent sembler inutiles, elles augmentent la compréhension humaine du projet et améliorent la vitesse et la qualité du changement. Il y a un équilibre, évidemment, j'ai vu des systèmes architecturés avec l'exigence apparente que tous les modèles de conception de logiciels soient utilisés partout. L'abstraction n'est utile que si elle améliore la lisibilité du code et la séparation des préoccupations.

Raison

L'un des contextes dans lesquels EF devient fastidieux est celui des tests unitaires. DbContext est un système compliqué, avec de nombreuses dépendances qu'il faudrait simuler manuellement avec beaucoup d'efforts. C'est pourquoi Microsoft a eu une idée : des fournisseurs de bases de données en mémoire. Donc, pour tester quoi que ce soit, il vous suffit d'utiliser une base de données en mémoire et d'en finir avec elle.

Notez que sur les pages Microsoft, cette méthode de test est désormais marquée « non recommandé ». Notez également que même dans ces exemples, EF est extrait par les référentiels.

Bien que les tests de base de données en mémoire fonctionnent, ils ajoutent plusieurs problèmes qui ne sont pas faciles à résoudre :

• la configuration d'un DbContext en mémoire nécessite toutes les dépendances aux entités existantes
• la configuration et le démarrage de la base de données mémoire pour chaque test sont lents
• Afin d'obtenir une sortie de base de données valide, vous devez configurer bien plus que ce que vous souhaitez tester atomiquement

Par conséquent, ce qui finit par arriver, c'est que les gens configurent tout dans la base de données au sein d'une méthode "d'aide", puis créent des tests qui commencent par cette méthode impénétrable et complexe pour tester même la plus petite fonctionnalité. Tout code contenant du code EF ne pourra pas être testé sans cette configuration.

Une des raisons d'utiliser des référentiels est donc de déplacer l'abstraction de test au-dessus de DbContext. Désormais, vous n'avez plus du tout besoin d'une base de données, juste d'une simulation de référentiel. Testez ensuite votre dépôt lui-même lors de tests d'intégration à l'aide d'une vraie base de données. La base de données en mémoire est très proche d'une base de données réelle, mais elle est également légèrement différente.

Une autre raison, que j'avoue avoir rarement vue avoir une réelle valeur dans la vie réelle, est que vous souhaiterez peut-être changer la façon dont vous accédez aux données. Peut-être souhaitez-vous passer à NoSql ou à un système de cache distribué à mémoire. Ou, ce qui est beaucoup plus probable, vous avez commencé avec une structure de base de données, peut-être une base de données monolithique, et vous souhaitez maintenant la refactoriser en plusieurs bases de données avec des structures de tables différentes. Laissez-moi vous dire d'emblée que cela sera IMPOSSIBLE sans référentiels.

Et spécifique à Entity Framework, les entités que vous obtenez sont des enregistrements actifs, mappés à la base de données. Vous apportez une modification à l'un et enregistrez les modifications pour un autre et vous obtenez également soudainement la première entité mise à jour dans la base de données. Ou peut-être que vous ne le faites pas, parce que vous n'avez pas inclus quelque chose ou que le contexte a changé.

Les partisans d'EF vantent toujours le suivi des entités comme une chose très positive. Disons que vous obtenez une entité de la base de données, que vous faites ensuite des affaires, puis que vous mettez à jour l'entité et que vous l'enregistrez. Avec un dépôt, vous obtiendriez les données, puis feriez des affaires, puis récupérez les données afin d'effectuer une petite mise à jour. EF le garderait en mémoire, saura qu'il n'a pas été mis à jour avant votre modification, donc il ne le lirait jamais deux fois. C'est vrai. Ils décrivent un cache mémoire pour la base de données qui est en quelque sorte conscient des modifications de la base de données et garde une trace de tout ce que vous gérez à partir de la base de données, sauf indication contraire, mappe de manière bidirectionnelle les entrées de la base de données avec des entités C# complexes et suit les modifications dans les deux sens, tout en étant profondément intégré. dans le code des affaires. Personnellement, je pense que cette pléthore de responsabilités et ce manque de séparation des préoccupations sont bien plus préjudiciables que toute performance obtenue en l'utilisant. En outre, avec quelques efforts initiaux, toutes ces fonctionnalités peuvent toujours être abstraites dans un référentiel, ou peut-être même dans une autre couche de mémoire cache pour un référentiel, tout en gardant des frontières claires entre l'activité, la mise en cache et l'accès aux données.

En fait, la vraie difficulté dans tout cela est de déterminer les frontières entre des systèmes qui devraient avoir des préoccupations distinctes. Par exemple, on peut gagner beaucoup de performances en déplaçant la logique de filtrage vers des procédures stockées dans la base de données, mais cela perd en testabilité et en lisibilité de l'algorithme utilisé. Au contraire, déplacer toute la logique vers le code, en utilisant EF ou un autre mécanisme, est moins performant et parfois irréalisable. Ou où est le point où les entités de données deviennent des entités commerciales (voir l'exemple ci-dessus avec Department et Person) ?

La meilleure stratégie est peut-être de commencer par définir ces frontières, puis de décider quelle technologie et quel design vont s'y intégrer.

Ma conclusion

Je pense que les abstractions de service et de référentiel doivent toujours être utilisées, même si le référentiel utilise Entity Framework ou un autre ORM en dessous. Tout se résume à la séparation des préoccupations. Je ne considérerais jamais Entity Framework comme une abstraction logicielle utile car elle comporte beaucoup de bagages, donc un référentiel peut être utilisé pour l'abstraire dans le code. EF est une abstraction utile, mais pour l'accès aux bases de données, pas dans les logiciels.

Ma philosophie de l'écriture de logiciels est que vous commencez par les exigences de l'application, que vous créez des composants pour ces exigences et que vous résumez toute fonctionnalité de niveau inférieur avec des interfaces. Vous répétez ensuite le processus au niveau suivant, en vous assurant toujours que le code est lisible et qu'il ne nécessite pas de compréhension des composants utilisés ou de ceux utilisés au niveau actuel. Si ce n’est pas le cas, vous avez mal séparé les préoccupations. Par conséquent, comme aucune application métier n’a jamais eu besoin d’utiliser une base de données ou un ORM spécifique, l’abstraction de la couche de données devrait masquer toute connaissance de ceux-ci.

Que veulent les entreprises ? Une liste filtrée de personnes ? var personnes = service.GetFilteredListOfPeople(filter); rien de moins, rien de plus. et la méthode de service ferait simplement return mapPeople(repo.GetFilteredListOfPeople(mappedFilter)); encore une fois, rien de moins ni de plus. La manière dont le repo récupère les personnes, les sauve ou fait autre chose ne relève pas du service. Vous souhaitez une mise en cache, puis implémentez un mécanisme de mise en cache qui implémente IPeopleRepository et a une dépendance sur IPeopleRepository. Vous souhaitez un mappage, implémentez les interfaces IMapper correctes. Et ainsi de suite.

J'espère ne pas avoir été trop verbeux dans cet article. J'ai spécifiquement gardé les exemples de code en dehors, car il s'agit davantage d'un problème conceptuel et non logiciel. Entity Framework est peut-être la cible de la plupart de mes plaintes ici, mais cela s'applique à tout système qui vous aide comme par magie dans les petites choses, mais brise les plus importantes.

J'espère que cela vous aidera !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!