Comment écrire la couche métier javaweb

Couche métier

Couche de service : Référencez l'opération de base de données Dao correspondante, où vous pouvez écrire le code dont vous avez besoin (comme un simple jugement).

La couche de service appelle diverses opérations commerciales Dao. Par exemple, si vous avez une entreprise qui est ajoutée puis modifiée. Ensuite, vous appelez respectivement les opérations d'ajout et de modification de dao, y compris une certaine conversion de données et un jugement logique dans la couche de service, et dao n'est qu'un simple ajout, suppression, modification et requête. Et les transactions sont généralement placées dans la couche service.
Étant donné que la couche Service et la couche DAO peuvent fonctionner sur la base de données, les différences spécifiques sont :

dao et service correspondent à

Généralement, Hibernate DAO n'exploite qu'un seul objet POJO, donc un DAO correspond à un objet POJO. La couche Service est destinée à la gestion des transactions (gestion déclarative des transactions) lors du traitement de plusieurs objets POJO (c'est-à-dire des opérations de données sur plusieurs tables). La couche Service (la classe d'implémentation de son interface) reçoit plusieurs objets DAO pour terminer ses opérations de données.

La présence ou l'absence de Service
Mon opinion sur ce point n'est peut-être pas correcte. Il y a deux modes dans mon esprit pour construire la couche métier :
le mode 1 est Service + DAO, c'est-à-dire que DAO effectue uniquement des CRUD et des opérations simples similaires (appelées points de fonction et n'inclut pas la logique métier) en appelant un ou plusieurs points de fonction dans le service DAO. Le numéro doit être déterminé par le module fonctionnel.
Dans ce modèle, la logique métier est placée dans le Service, et les limites de la transaction doivent également être contrôlées dans le Service. Bien entendu, le contrôle des transactions directement dans le Service introduira du code logique non métier. AOP peut résoudre ce problème, c'est aussi l'une des raisons de l'introduction de Spring
Si nous parlons des lacunes, c'est que les opérations sur certains objets sont de simples CRUD, et la couche Service semble encombrante. >

Le mode 2 est Service + BO, et BO = DAO + méthode métier, ajoutez des méthodes métier sur la base du DAO d'origine pour former un objet BO. Il convient de noter que les méthodes métier dans BO sont souvent ciblées sur un seul objet entité. Si elles doivent s'étendre sur plusieurs objets entité, la méthode doit être placée dans Service.

Par exemple,

Un simple système de gestion de compte bancaire crée un objet BO de compte, qui peut contenir des changements de mot de passe, retirer. l'argent et d'autres méthodes commerciales (il n'est pas difficile de voir que ces méthodes ne fonctionnent que sur un seul objet de compte). Nous devons maintenant ajouter une méthode de transfert, qui doit être placée dans Service.

Quelle est la relation entre Service et BO ici ? Autre exemple :

Prenons l'exemple des agences administratives nationales : le Bureau des céréales est chargé de la collecte des céréales, de la vente des semences, etc., et le ministère de la Construction est chargé d'approuver les ventes de terrains, la construction de routes. , etc. Ce sont toutes des questions relevant du département administratif Son. Soudain, il y a une inondation à un certain endroit. Pendant les secours en cas de catastrophe, le Bureau des céréales doit ouvrir un entrepôt pour libérer les céréales, et le ministère de la Construction construit des maisons temporaires. Comment coordonner les deux départements ? Il est nécessaire de créer un comité spécial de secours en cas de catastrophe, qui répartira les ressources des deux parties. Les deux parties ici sont BO et le comité de secours en cas de catastrophe est Service. Je ne sais pas si j’ai exprimé ce que je voulais dire avec précision, haha. Le mode 1 a des limites claires lors de la division du service et du DAO, mais il apportera du code inutile. Le partitionnement du mode 2 est relativement complexe, mais il peut améliorer l'efficacité du codage.

Bien entendu, dans les applications à petite échelle, il est acceptable d'utiliser DAO ou BO sans service.

S'il existe des interfaces entre le Service et DAO

L'interface est un contrat, qui peut avoir plusieurs implémentations. Par conséquent, la présence ou l’absence d’interfaces dépend de la nécessité ou non de diversifier l’implémentation spécifique. S’il est déterminé qu’il n’existe qu’une seule implémentation d’un DAO ou d’un service, il n’y a alors que peu de sens à faire abstraction de l’interface. Cependant, certaines grandes applications peuvent nécessiter plusieurs implémentations de DAO et de service (comme le compte DAO dans l'exemple ci-dessus, qui peut nécessiter une implémentation Hibernate, une implémentation CMP et une implémentation JDO afin de masquer la classe d'implémentation spécifique). niveau supérieur, vous devez utiliser des interfaces.

Masquer le processus de création de classes d'implémentation spécifiques. Il existe deux méthodes : l'une est la méthode pratique de l'usine, qui coûte une grande quantité de code (une usine pour chaque DAO et service). La seconde consiste à utiliser l'IoC de Spring pour implémenter l'injection de dépendances sans écrire de code supplémentaire. C'est également la deuxième raison de l'introduction de Spring.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!