Où placer la logique métier dans la conception MVC?

J'ai 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, les valide et les stocke également. En effet, les données proviennent de différents utilisateurs. les données sont principalement numériques.

Maintenant, sur les données numériques stockées dans la base de données (serveur SQL), je souhaite que mon application effectue des calculs et affiche les résultats. L'utilisateur n'est pas intéressé par la façon dont les calculs sont effectués, ils doivent donc être encapsulés. L'utilisateur doit uniquement pouvoir afficher les données calculées simples (par exemple, les données de colonne A moins les données de colonne B divisées par les données de 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 je saisis dans la base de données soient archivées et que des calculs soient effectués. Les données d'origine ne doivent pas être affectées, tandis que les nouvelles données, post-calculs, doivent être stockées en tant que nouvel enregistrement d'entité dans la base de données.

Où devrais-je écrire le code pour ce calcul en arrière-plan? Comme ce sont les règles et la logique métier, devrais-je le mettre dans de nouveaux fichiers JavaBeans?

— BriskLabs Pakistan
source

duplication possible de Staying OO et Testable avec une base de données

— gnat le

Réponses:

La logique métier doit être placée dans le modèle , et nous devrions viser les gros modèles et les contrôleurs minces .

Comme point de départ, nous devrions commencer par la logique du contrôleur. Par exemple: lors de la mise à jour , votre contrôleur doit diriger votre code vers la méthode / le service qui fournit les modifications apportées au modèle.

Dans le modèle, nous pouvons facilement créer des classes d' assistance / de service dans lesquelles les règles commerciales ou les calculs de l'application peuvent être validés.

Un résumé conceptuel

Le contrôleur est destiné à la logique d'application. La logique qui est spécifique à la façon dont votre application veut interagir avec le "domaine de la connaissance" auquel elle appartient.
Le modèle concerne une logique indépendante de l'application . Cette logique devrait être valable dans toutes les applications possibles du "domaine de la connaissance" auquel elle appartient.
Il est donc logique de placer toutes les règles de gestion dans le modèle.

— EL Yusubov
source

belle réponse claire et concise ..

— hanzolo

@Yusubov, pourriez-vous m'expliquer la différence entre la logique d'application et la logique métier

— Mohamad

@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 en fonction de spécifications fonctionnelles. Par exemple, les objets A de type B doivent avoir été attribués à C et D, mais pas à E. La logique d'application est davantage une spécification technique, telle que l'utilisation de servlets Java et d'OJB pour persister dans une base de données Oracle.

— EL Yusubov

Souhaitez-vous s'il vous plaît expliquer 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 ]

— révo

Si j'ai bien compris, l'article mentionné fait référence à la «logique d'application» en tant que «logique métier». Ainsi, tout ce qui fait référence à la logique applicative ne doit pas être placé dans le contrôleur ou la vue.

— EL Yusubov

Comme toujours, cela dépend de la complexité du projet.

Dans les applications triviales, où la complexité du modèle de domaine est relativement petite, vous pouvez insérer la logique dans les modèles et l'appeler un jour.

Cependant, pour des 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 définissez 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 modelssavoir trop. Et cela se transformera rapidement en un grand désordre difficile à tester et à entretenir. Donc, dans ce cas, il est avantageux de placer la logique dans un calque séparé.

Lorsque vous décidez de l'abstraction, tenez toujours compte de la complexité et des objectifs de votre application, et évitez les sur-techniques. Pour les applications triviales / petites, introduire plus de couches que nécessaire augmente la complexité au lieu de la réduire.

Robert Martin (Oncle Bob) a publié un bon article sur ce sujet: The Clean Architecture.

— Hakan Deryal
source

la question était spécifique à MVC. la logique métier doit toujours figurer dans le modèle. Le contrôleur est juste un adaptateur.

— jgauffin

MVC est l’un des termes les plus surchargés du secteur. Je ne veux pas entrer dans les bizarreries de ce terme, car il mérite un livre. Simplement, utiliser MVC ne signifie pas que vous devez mettre toutes les logiques dans les modèles.

— Hakan Deryal

De la définition par 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

. C'est une définition d'adaptateur.

— Jgauffin

Si vous mettez toute la logique dans le modèle, vous vous retrouverez avec des milliers de lignes de bordel incontrôlables. Été là. Ce n'est pas un péché d'avoir des classes d'utilitaires et une couche de service.

— asthasr

Je pense que jgauffin voulait en venir au fait 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 toute la logique métier appartient au "modèle", mais le "modèle" peut englober plusieurs classes et couches, y compris des "classes utilitaires" et "une couche de service". En d'autres termes, nous ne dirions pas que la couche de service fait partie du contrôleur ou de la vue. Par conséquent, le modèle le mieux adapté.

— DavidS

L'intégration de la logique métier dans le modèle peut sembler la meilleure voie à suivre. Le contrôleur reçoit un appel de l'application Web distante. Le contrôleur du service Web MVC prend l'appel et redirige l'exécution vers une méthode de BL. Désormais, Business Logic peut être contenu dans le "Modèle", mais peut également être placé dans un autre dossier, par exemple "Business Logic" . Il n’existe donc aucune règle stricte sur l’emplacement de la logique commerciale.

J'utilise un service web construit sur MVC 3.0 et le conteneur de la logique métier est le MVC MODEL .

— Monty Python
source

Je suis d'accord. Vous obtenez une application beaucoup plus flexible lorsque votre modèle est simplement une structure de données sur laquelle agissent d'autres classes de logique métier. À titre d’exemple simple, j’estime que l’approche d’ASP.NET en matière de validation à l’aide d’attributs a échoué. Si j'annote la propriété FirstName d'une personne avec l'attribut Required, qu'arrivera-t-il si je crée une vue d'administrateur 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.

— xr280xr