Comment faire la distinction entre la logique métier et la logique de stockage dans le développement back-end?

Architecture à trois couches arrière: la frontière entre la logique métier et la logique d'accès aux données

En développement back-end, les architectures courantes à trois couches du contrôleur, du service et du DAO sont relativement claires dans les couches de contrôleur et de service. Ils sont principalement implémentés en séparant la logique métier et la logique de présentation, tels que le découplage de la file d'attente de messages (MQ), HTTP, RPC, etc. de la logique métier. Cependant, la frontière entre la couche de service et la couche DAO, en particulier après l'introduction de la couche de gestionnaire, confond souvent les développeurs.

Dans le développement de python back-end, la logique métier est parfois mélangée dans la couche de modèle, telles que les méthodes de requête commerciale telles que usermodel.is_super() , ou des opérations de base de données natives telles que usermodel.objects.all() , et même des opérations de table croisée telles que usermodel.** .

Analyse de la logique commerciale et de la logique non commerciale

La clé de la logique métier et de la logique non commerciale réside dans la question de savoir si elle se rapporte directement aux besoins des clients. Logique que les clients ne peuvent pas percevoir sont souvent considérées comme une logique non commerciale, notamment:

1. Structure de la base de données et relation d'association: par exemple, usermanager.delete() et departmentmanager.delete() peuvent gérer la suppression du tableau d'association (telles que userdeptmodel ) en même temps, sans appeler la méthode de la couche DAO deux fois au niveau de la couche de service. Même sans couche de gestionnaire, la couche DAO peut effectuer de telles opérations d'association ou de table transversale tant que ces opérations sont indépendantes de la logique commerciale.

    classe Usermanager:
       Def supprimer (soi):
           userdao.delete ()
           userDeptDao.Delete ()
   Département de département de classe:
       Def supprimer (soi):
           DepartmentDao.Delete ()
           userDeptDao.Delete ()

2. Mot de passe Salt: Les utilisateurs doivent seulement savoir que le mot de passe n'est pas stocké en texte brut, et l'opération d'addition de sel peut être traitée dans la couche DAO ou Manager.

    Classe UserDao:
       def make_password (self, passwd):
           return sel (passwd) # ajouter la fonction de sel def Save (self):
           self.passwd = self.make_password (self.passwd)
           super (). Save ()

3. Nommer et définition de la méthode de la couche DAO: la méthode de la couche DAO, par exemple, si les noms sémantiques tels que get_super_user conviennent à ce qu'ils soient liés à la logique métier. Si super n'est pas lié aux entreprises, il est acceptable d'utiliser get_super_user .

4. L'encapsulation de la demande HTTP: les dépendances backend (telles que les services fournis par d'autres équipes) peuvent être encapsulées en méthodes DAO-couche, plutôt que des méthodes de couche de service.

Implémentez des fonctions similaires au filtre Django dans Django / Flask

Lors de la mise en œuvre de fonctions de type filtre Django dans Django et Flask, vous rencontrez souvent des problèmes de pénétration de couche par couche car la couche DAO doit passer dans les paramètres de demande. En l'absence d'un cadre d'injection de dépendance comme le printemps, vous pouvez considérer:

• Dans Java, des cadres tels que MyBatis ou JPA sont généralement utilisés pour gérer l'accès aux données et le filtrage de la logique via des annotations et des fichiers de configuration.

La relation entre les entités de données et l'architecture à trois couches

Les entités de données représentent des objets de données dans le système. Dans une architecture à trois couches, le contrôleur, le service et les couches DAO ne correspondent pas strictement à un par un:

• La couche DAO peut contenir plusieurs méthodes pour traiter différentes entités de données, telles que userdao et departmentdao .
• La couche de service peut avoir besoin de combiner plusieurs méthodes de couche DAO pour implémenter une logique commerciale complète.

En bref, la couche DAO n'est responsable que de l'interaction de stockage des données et n'inclut pas la logique métier; La couche de service est responsable de l'exécution de la logique commerciale. Par exemple, lors de la création d'un utilisateur, la couche de service vérifie si le nom d'utilisateur est dupliqué, puis appelle la méthode de couche DAO pour enregistrer l'utilisateur. Cette architecture est conçue pour diviser le système par responsabilité et améliorer la maintenabilité et l'évolutivité du code.

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!