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?

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.

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.

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 .