Modèle de référentiel avec couche de service - trop de séparation?
J'ai un site MVC qui utilise le modèle de référentiel. Je n'ai pas l'impression d'utiliser suffisamment le style MVC, alors je me prépare à en ré-architecturer une partie. Mais je veux aussi le faire, donc si le front-end change, il sera plus facile de permuter.
Voici ce que j'ai actuellement
Modèles - certains de mes modèles contiennent directement mes entités/classes. (Le modèle de connexion contient la classe Customer, qui est une corrélation directe avec la classe de table/référentiel Customer) Vues - certaines de mes vues contiennent des requêtes repo - ie
_customerRepo.Query().FirstOrDefault(c => c.Login == User.Identity.Name);
Contrôleurs - Pas aussi important ici, les contrôleurs appellent des requêtes de repo, et certains d'entre eux utilisent également certains services pour appeler le repos - ie
_customerService.GetAllCustomers()
qui appelle
_customerRepo.Query().All();
Voici mes pensées:
1) Les modèles doivent contenir UNIQUEMENT les données devant être présentées sur la vue. Même si toutes les propriétés de la table/objet Customer sont présentées dans la vue, elles doivent être réécrites dans leur propre modèle/classe afin que la vue ne sache rien de l'architecture de la base de données ou des objets backend
2) Les vues ne doivent accéder qu'aux objets du modèle
3) (Et c'est là que je me bats sur la voie à suivre)
a) Les contrôleurs (ou quelque part du côté MVC, devraient être du code qui convertit les données d'objet renvoyées par le référentiel/services et les convertit en modèles. Je suppose que je pourrais simplement placer ce code dans un constructeur de modèle. Mais je '' ai remarqué que DI attend un constructeur vide par défaut en cas d'erreurs de validation
b) Les contrôleurs appellent des interfaces repo sur des méthodes bien nommées pour récupérer des données (c'est-à-dire _customerRepo.GetAllCustomers ()
c) Les contrôleurs accèdent UNIQUEMENT à une couche de service. La couche service est alors la seule chose qui interagit avec la couche repo.
Suis-je en train d'extraire trop les couches modèle, contrôleur, service, repo? La couche serivces est-elle trop lourde car tout peut être fait par les repos?
Quelle est l'approche recommandée pour convertir les objets/entités commerciales en modèles?
Oui, la couche de service est une surcharge si vous ne disposez d'aucune logique métier. L'architecture en couches ressemble à une surcharge lorsqu'une couche (dans votre service de cas) ne fait pas grand-chose. Mais une architecture en couches fournit votre couplage lâche qui est généralement bon pour adapter les exigences à l'avenir.
Si vous pouvez garantir que vous n'aurez jamais rien à faire dans la couche de service, sauf la copie des données du référentiel vers le modèle, vous pouvez supprimer la couche de service dans votre conception. Cependant, si votre application est basique, vous n'avez pas à vous soucier d'ajouter une autre couche pour des raisons de performances ou pour toute autre raison.
Personnellement, je garderai la couche service et (dépend de la technologie) implémentera une couche DAO/Repository générique.
Cela dépend de vos référentiels concrets, mais d'une manière générale, j'ajouterais une couche de service au-dessus des référentiels.
Selon l'implémentation de votre référentiel, ils peuvent être spécifiques à votre magasin de persistance. Cela facilite également les tests et conduit à une architecture hexagonale, au lieu d'une architecture en couches classique (que je considère comme un avantage), voir https://blog.8thlight.com/uncle-bob/2012/08/ 13/the-clean-architecture.html .