java - Dans le modèle de développement MVC, l'objet encapsulé doit-il être placé dans un contrôleur ou un service? Comment le contrôleur et le service doivent-ils interagir ?

Question

J'étudie MVC depuis deux ans, mais certains concepts sont encore vagues. J'espère pouvoir trouver la réponse ici.

J'ai vu une fois quelqu'un dire que le contrôleur n'est pas responsable du traitement des données et que tout est géré par notre service. Quel que soit le type de données renvoyé depuis le front-end de la page Web, le type de données est directement transmis au service et. alors le service le gère ; mais une autre voix dit que parfois plusieurs services sont appelés en même temps si l'objet est encapsulé dans le contrôleur, il sera évité plusieurs fois dans la méthode Service.

Une autre question concerne l'interaction entre le contrôleur et le service.
Afin de garantir une bonne interaction client sur le front-end, nous renvoyons souvent certaines invites d'erreur au front-end via le contrôleur, telles que le nom d'utilisateur existe déjà, le nom d'utilisateur et le mot de passe ne correspondent pas, etc. Cependant, nous traitons la logique métier dans la couche Service. Si nous définissons la valeur de retour d'une méthode login (String username, String password) sur booléen, nous ne pouvons pas renvoyer plusieurs erreurs. Cependant, si nous renvoyons le type String, nous devons le faire. définir quelques paramètres de base.
Ma propre "idée géniale" est que je lance des RuntimeExceptions personnalisées dans le service, puis que j'utilise TryCatch dans le contrôleur pour gérer différentes erreurs, mais je pense que cette façon de lancer des exceptions est inappropriée. J'ai été confus récemment et je suis sur le point de commencer à travailler sur mon prochain projet. J'espère que vous pourrez m'aider à dissiper ma confusion.

Merci.

Answer 1

Notre projet est divisé en trois niveaux :

1. Couche de présentation : Spring MVC, responsable de la réception des requêtes HTTP, de l'affichage (du renvoi) des résultats et de la vérification simple

2. Couche d'application : fournit des fonctions de couche d'application, telles que l'importation, l'exportation et la vérification complexe

3. Couche de domaine : gère la logique métier, comme certains services

La séquence d'appel est unique : Contrôleur->App->Domaine

Et la relation de perception est la suivante : Contrôleur->Application->Domaine, c'est-à-dire que la couche inférieure ne perçoit pas la couche supérieure

Permettez-moi d'abord de répondre à votre première question :

Puis-je comprendre que la première question que vous avez mentionnée signifie que les paramètres reçus par la requête HTTP ne sont pas des objets, mais un ensemble de types de base, mais que les paramètres reçus par votre service sont des objets. L'approche correcte devrait être de convertir le paramètre « brut » en un objet Object dans le contrôleur, puis d'appeler le service.

Pourquoi est-ce correct ? Étant donné que le service appartient à la couche Domaine, qui contient la logique métier, les paramètres qu'il accepte doivent être conçus en fonction de vos propres besoins. Vous ne devez pas prendre en compte les paramètres de la couche Web, afin qu'ils puissent être réutilisés dans différents scénarios.

Par exemple, votre service doit être réutilisable dans différents environnements de couche de présentation :

1. Dans un programme web, les paramètres passés par l'utilisateur vous sont donnés sous forme de POST/GET

2. Dans un programme de service Web, les paramètres passés par l'utilisateur sont json ou SOAP

3. Dans un programme Swing, les paramètres passés par l'utilisateur sont des chaînes

Si vous liez le service à un environnement de couche de présentation spécifique, ses paramètres de méthode seront définitivement instables, ce qui entraînera l'impossibilité de les réutiliser.

De même, la valeur de retour du service ne doit pas être liée au scénario spécifique.

Au niveau Spring MVC, Controller peut facilement convertir les paramètres en objets, documents associés

Deuxième question :

Cette question peut être divisée en trois parties :

1) Où faire une vérification simple telle que la limite de longueur des paramètres, le jugement non vide, etc. ?

Une vérification simple est effectuée à l'aide du mécanisme fourni par Spring MVC lui-même, des documents associés, des documents associés

2) Où la vérification est-elle effectuée en parallèle avec la logique métier du Service lui-même, comme par exemple déterminer si le compte de l'utilisateur est désactivé lors de la passation d'une commande ?

J'ai tendance à effectuer ces vérifications logiques sur la couche Application. Le contrôleur appelle l'application, et l'application appelle deux services différents pour relier l'entreprise

3) Comment vérifier la logique métier liée au Service lui-même

Vous avez donné un exemple de connexion. Il n'y a aucun problème à utiliser des exceptions pour informer l'appelant (contrôleur) des résultats du traitement. Vous pouvez également enrichir la valeur de retour de Service pour atteindre cet objectif, mais il convient de noter que la conception de la valeur de retour de Service ne peut pas être liée à l'environnement de la couche de présentation, sinon elle ne peut pas être réutilisée. C'est pourquoi @YaTou a mentionné apache-shiro. Un mécanisme d'exception est utilisé pour gérer les échecs d'authentification, car seul celui-ci est assez général.

Answer 2

Je pense qu'il est exact que Controller n'est pas responsable du traitement des données, car Controller ne peut pas être réutilisé dans spring-mvc, mais si vous la logique métier est abstraite dans Service, alors ce Service peut être réutilisé.Controller不负责处理数据是正确的, 因为在spring-mvc中Controller是不能复用的, 但是如果你把业务逻辑抽象成Service, 那么这个Service就是可以复用的.

至于你说的 "在Controller就将对象封装好了，就免于在Service的方法中多次封装" , 没太明白什么意思, 你每个Service需要什么参数, Controller就给什么参数, 至于需要的参数是否需要封装成对象就可以自己权衡了.

你所说的login(String username,String password), 你想抽象成Service用异常处理处理多种不同的结果, 这个我觉得完全没有问题, 而且我觉得非常好啊, 很多认证框架都用的这种方式, 至少我看的apache-shiro

Quant à ce que vous avez dit "encapsuler l'objet dans le Controller, vous n'avez pas besoin de l'encapsuler plusieurs fois dans la méthode Service", je ne comprends pas très bien ce que vous voulez dire. De quels paramètres avez-vous besoin pour chaque . Service ? Controller vous donne simplement tous les paramètres. Quant à savoir si les paramètres requis doivent être encapsulés dans des objets, vous pouvez le peser vous-même.🎜 🎜Ce que vous avez dit à propos de login(String username,String password), vous souhaitez le résumer dans Service et utiliser la gestion des exceptions pour gérer plusieurs résultats différents, je pense qu'il n'y en a pas. Cela pose un problème. Et je pense que c'est très bien. De nombreux frameworks d'authentification utilisent cette méthode. Au moins celui que j'ai examiné apache-shiro utilise des exceptions pour gérer différentes situations d'échec d'authentification.🎜

Answer 3

Il n'y a pas de réponse standard à la première question. Il est préférable d'analyser la situation spécifique et de rendre la stratification logique claire et facile à maintenir.

En ce qui concerne la deuxième question, l'interaction que vous avez donnée ici est soumise au contrôle d'autorisation. Généralement, le filtre, l'aop, le proxy, la réflexion, etc. peuvent être utilisés pour réaliser la fermeture du code. Des exceptions sont également levées une fois dans ces codes de contrôle centralisés. bien, mais je trouve fastidieux de le coder en dur directement dans le contrôleur. La couche Service consiste davantage à appeler les méthodes de la couche Dao pour implémenter un traitement de logique métier complexe impliquant plusieurs tables. Les transactions sont également placées sur cette couche (bien sûr, le framework a fait tout cela maintenant), donc la couche Service ne le fait généralement pas. lancer des exceptions (la vérification des paramètres est effectuée dans le contrôleur et les couches précédentes, donc aucune exception liée à l'entreprise ne se produit et Dao bloque les exceptions sous-jacentes liées à la base de données).

Bien sûr, c’est un avis personnel, il n’y a pas de formule fixe, comme je l’ai dit, c’est bien si les couches sont claires et faciles à entretenir.

Answer 4

1. Le contrôleur est singleton par défaut, mais il peut être remplacé par @Scope(value = "prototype")

2. La connexion peut renvoyer un int, ajouter une énumération par vous-même

3. Il est stipulé que la logique est traitée au niveau de la couche Service. Cela dépend du métier. Il vaut mieux avoir moins de redondance de code et l'optimiser

.

Tout le monde a des opinions différentes. Ce qui est plus important pour le développement, c'est l'optimisation, la modification et la réduction de la redondance, plutôt que ce qui doit être fait. . .

Answer 5

1. Le contrôleur ne doit pas concevoir de logique métier autant que possible, impliquer uniquement une interaction
2. Le service est une logique métier réutilisable
3. Le contrôleur est l'appelant supérieur du service
4. Renvoyez la valeur, portez un jugement au niveau de la couche Contrôleur et lancez l'exception correspondante souhaitée.

Bien sûr, il ne s'agit que de notre approche actuelle, merci de la partager. . .

Answer 6

Vous pouvez lire mon article
AOP, MVC - Spring learning et réflexion sur CodeIgniter /a/11...

Answer 7

Il est recommandé que la logique soit placée dans le service. Nous travaillons actuellement sur une architecture de microservice distribuée. Nous la placions sur la couche contrôleur, nous la recréions en gros. que les applications doivent utiliser ne peuvent pas être partagées si elles sont placées sur le contrôleur.

Answer 8

Le fait que l'objet encapsulé soit dans le Contrôleur ou dans le Service dépend de la situation spécifique. Je pense personnellement que s'il s'agit d'un simple paramètre, il est parfaitement correct de l'encapsuler dans le Contrôleur. S'il est placé dans le Service, il le sera. semblent très redondants et conduisent à une détérioration de la polyvalence du service ; pour la deuxième question, il n'est pas permis d'utiliser des énumérations ou des codes d'état différents pour porter des jugements sur le contrôleur et lancer des exceptions. Vous pouvez définir complètement un ensemble de mécanismes de gestion des exceptions. par vous-même et lancez-les directement sur la couche Service. Le projet a ciblé ce mécanisme de gestion des exceptions de type professionnel qui renvoie directement le message d'erreur du service et le code d'erreur à la couche View, permettant au client de les gérer en fonction du code d'état et message d'erreur