Lors de la planification de l'architecture d'une application Web MVC à moyenne et grande échelle, comment implémentez-vous les couches pour qu'elles soient aussi découplées que possible et faciles à tester? (suivez essentiellement les meilleures pratiques) Supposons que j'utilise d'abord le code comme accès aux données.
J'ai du mal à définir la "logique métier" et comment elle doit interagir avec la couche de données. En prenant une application de vente de véhicules comme exemple, la logique commerciale serait-elle des classes qui effectuaient des tâches telles que le calcul de la fourchette de taxe pour des véhicules donnés, la comparaison de statistiques de mile par gallon, etc.? Quant aux entités commerciales (par exemple les voitures, les fourgonnettes, les motos), je les mettrais dans la couche de données avec ma DataContext
classe.
De plus, qu'est-ce qui constituerait une logique d'application par opposition à une entreprise - je suppose des choses comme des validations d'entrée de session / utilisateur?
Ainsi, par exemple, un contrôleur de voiture peut retourner un résultat d'action / vue qui répertorie les dix meilleures voitures filtrées par type et meilleur mpg. Alors disons que j'ai un ICarRepository
'carRepo' injecté dans mon contrôleur (en utilisant le modèle de référentiel / DI), je filtre mes voitures à partir d'un paramètre de méthode d'action, par exemplevar cars = carRepo.getCarsByType("hatchback");
J'ai donc gardé les connaissances d'accès aux données hors de mon contrôleur en utilisant un référentiel, maintenant pour garder la logique métier hors du contrôleur en utilisant un modèle de domaine - var result = new MpgCalculator (cars); - Disons que j'ai besoin de la classe de calculatrice car elle doit effectuer une logique supplémentaire pour calculer la meilleure efficacité énergétique, plus que simplement charger / filtrer des entités à partir de la base de données. Alors maintenant, j'ai un ensemble de données à afficher pour ma vue qui utilise un référentiel pour récupérer à partir de la couche d'accès aux données, et un objet spécifique au domaine pour traiter et effectuer des tâches liées à l'entreprise sur ces données.
Suis-je en train de faire des erreurs ici? avons-nous encore besoin d'utiliser le modèle de référentiel ou puis-je simplement coder contre une interface pour découpler l'ORM et tester? À ce sujet, comme mes classes concrètes d'accès aux données dbcontext sont dans la couche de données, les définitions d'interface doivent-elles aller dans la couche domaine / entreprise, ce qui signifie que si la technologie d'accès aux données est modifiée, mes autres couches ne sont pas affectées?
D'après ce que j'ai étudié jusqu'à présent, ma structure ressemble à ceci:
Application Internet MVC -> Le projet Internet standard - les modèles ici sont ViewModels
Couche domaine / entreprise -> classes / modèles spécifiques à l'entreprise que les contrôleurs peuvent utiliser pour traiter les entités de domaine de la couche de données avant de passer aux vues pertinentes
Abstraction du référentiel nécessaire? -> J'entends beaucoup de débats à ce sujet, en particulier lors de l'utilisation d'un ORM
Couche de données -> Classes d'entité (voiture, fourgonnette, moto), DbContext - Couche de technologie d'accès aux données concrètes