Jai créé une application Java MVC simple qui ajoute des enregistrements via des formulaires de données à une base de données.
Mon application collecte des données, elle les valide également et les stocke. En effet, les données proviennent en ligne de différents utilisateurs. les données sont principalement de nature numérique.
Maintenant que les données numériques sont stockées dans la base de données (serveur SQL), je veux que mon application effectue des calculs et affiche les résultats. Lutilisateur nest pas intéressé par la façon dont les calculs sont effectués, ils doivent donc être encapsulés. Lutilisateur doit uniquement pouvoir afficher les données calculées simples (par exemple, les données de la colonne A moins les données de la colonne B divisées par les données de la colonne C). Je sais comment écrire des procédures stockées pour la même chose, mais je veux une application à trois niveaux.
Je veux que les données que jai placées dans la base de données sous forme denregistrement, soient traitées en effectuant des calculs dessus. Les données dorigine ne doivent pas être affectées, tandis que les nouvelles données, post-calculs, doivent être stockées en tant que nouvel enregistrement dentité dans la base de données.
Où dois-je écrire le code pour ce calcul darrière-plan? Comme il sagit des règles et de la logique métier, dois-je le mettre dans de nouveaux fichiers JavaBeans?
Commentaires
- duplication possible de Rester OO et testable tout en travaillant avec une base de données
- La logique métier est lalias dun membre de votre équipe / service à qui vous demandez comment faire / opérer sur un modèle. Cest ‘ pourquoi, la logique métier peut être stockée dans une classe séparée nommée Logique métier. Il en va de même pour Presentation Logic, synonyme dun concepteur qui répond à vos questions sur la mise en forme ou laffichage des composants de linterface utilisateur. Il peut également y avoir une logique de développement (questions que vous posez et répondez par vous-même ou posez à vos collègues) qui représente une connaissance sur la façon de créer et de connecter les composants dun programme ensemble.
Réponse
La logique métier doit être placée dans le model , et nous devrions viser des modèles gros et des contrôleurs .
Pour commencer, nous devrions partir de la logique du contrôleur. Par exemple: lors de la mise à jour , votre contrôleur doit diriger votre code vers la méthode / service qui fournit vos modifications du modèle.
Dans le modèle, nous pouvons facilement créer un helper / service classes où lapplication règles métier ou calculs peut être validée.
Un concept résumé
-
Le contrôleur est destiné à la logique dapplication. La logique qui est spécifique à la manière dont votre application souhaite interagir avec le » domaine de connaissances » auquel il appartient.
-
Le modèle est destiné à une logique indépendante de lapplication . Cette logique doit être valable dans toutes les applications possibles du » domaine de connaissances » auquel il appartient.
-
Ainsi, il est logique de placer toutes les règles métier dans le modèle.
Commentaires
- belle réponse claire et concise ..
- @Yusubov, pourriez-vous mexpliquer la différence entre la logique applicative et la logique métier
- @Moh, En bref, ce sont des mots à la mode pour aider décrire les niveaux de technologie dans une application. La logique métier est essentiellement des règles du système selon les spécifications fonctionnelles. Par exemple, lobjet A de type B doit avoir attribué C et D, mais pas E. La logique dapplication est davantage une spécification technique, comme lutilisation de servlets Java et dOJB pour persister dans une base de données Oracle.
- Voudriez-vous sil vous plaît élaborer sur ces mots:
The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.[ php-html.net/tutorials/model-view-controller-in-php] - Si jai bien compris, larticle mentionné fait référence à la ‘ logique dapplication ‘ en tant que ‘ logique métier ‘. Ainsi, tout ce qui fait référence à la logique métier ne doit pas être placé dans le contrôleur ou la vue.
Réponse
Comme toujours, cela dépend de la complexité du projet.
Dans les applications triviales, où la complexité du modèle de domaine est relativement faible, vous pouvez mettre la logique dans les modèles et lappeler un jour.
Cependant, pour les applications non triviales avec des modèles complexes et de nombreuses règles métier, il est préférable de séparer un peu plus les choses.
Si vous mettez la logique métier qui implique plusieurs modèles dans un modèle, vous introduisez un couplage étroit entre ces modèles.Au fur et à mesure que les applications se développent, ces modèles ont tendance à se transformer en god models, en sachant trop. Et cela se transformera rapidement en un gros gâchis difficile à tester et à entretenir. Dans ce cas, il est donc avantageux de placer la logique dans une couche séparée.
Lorsque vous décidez de labstraction, tenez toujours compte de la complexité et des objectifs de votre application, et évitez de sur-ingénierie. Pour les applications triviales / petites, introduire plus de couches quil nen faut augmente la complexité au lieu de la réduire.
Robert Martin (Oncle Bob) a un bon article sur ce sujet: The Clean Architecture.
Commentaires
- la question était spécifique à MVC. la logique métier doit toujours figurer dans le modèle. Le contrôleur nest quun adaptateur.
- MVC est lun des termes les plus surchargés de lindustrie. Je ne ‘ t vouloir entrer dans les bizarreries de ce terme, car il justifie un livre. Simplement, utiliser MVC nimplique ‘ que vous devez mettre toutes les logiques dans les modèles.
- Daprès la définition de Steve Burbeck (équipe Smalltalk):
The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Cest ‘ une définition dadaptateur. - Si vous mettez toute la logique dans le modèle, vous vous retrouverez avec des milliers de lignes de désordre impossible à maintenir. Été là. Ce ‘ nest pas un péché davoir des classes dutilité et une couche de service.
- Je pense que jgauffin voulait en venir, cest que la question est spécifique à MVC. Si nous acceptons de voir le système du point de vue MVC et uniquement du point de vue MVC, alors oui, toute la logique métier appartient au modèle » « , mais le » modèle » peut englober plusieurs classes et couches, y compris » classes dutilité » et » une couche de service » . Pour le dire autrement, nous ne ‘ t dire que la couche de service fait partie du contrôleur ou de la vue, donc le modèle est le mieux adapté.
Réponse
Mettre la logique métier à lintérieur du modèle peut sembler la meilleure solution. Le contrôleur reçoit un appel de lapplication Web distante. Le contrôleur du service Web MVC prend lappel et redirige lexécution vers une méthode dans BL. Désormais, Business Logic peut être contenu dans le « Model », mais peut également être positionné dans un autre dossier, par exemple « Business Logic » . Il ny a donc pas de règle absolue sur la destination de la logique métier.
Jutilise un service Web basé sur MVC 3.0 et le conteneur de la logique métier est le MVC MODEL .
Commentaires
- Je suis daccord. Vous obtenez une application beaucoup plus flexible lorsque votre modèle est simplement une structure de données exploitée par dautres classes de logique métier. À titre dexemple simple, je pense que cest un gros échec de lapproche de validation dASP.NET ‘ en utilisant des attributs. Si jannote la propriété FirstName dune Person ‘ avec lattribut Required, que se passe-t-il si je crée une vue dadministration où FirstName ne devrait pas être requis? Une couche de logique métier doit consommer le modèle et déterminer les actions appropriées pour celui-ci.