Style de codage: environnement SSM en mode Mvc, gestion des couches de code

Code source de cet article: GitHub · cliquez ici || GitEE · cliquez ici

1. Stratégie de stratification

Modèle MVC et stratégie de superposition de code. Le nom complet de MVC est ModelViewController, qui est model-view-controller. En tant que modèle de conception logicielle, il organise le code de manière à séparer la logique métier, les données et l'affichage de l'interface, et rassemble la logique métier en un seul. Dans le composant, tout en améliorant et en personnalisant l'interface et l'interaction utilisateur, il n'est pas nécessaire de réécrire la logique métier. Il s'agit d'un mode de développement, mais ce n'est pas un mode en couches du code en développement réel. Habituellement, le code back-end du framework SSM est divisé en Les couches sont les suivantes:

• Couche de contrôle du contrôleur: définissez l'interface du serveur, les paramètres d'entrée et de sortie et vérifiez certains paramètres d'entrée;
• couche de service métier: assemblage de la logique métier, vérification métier et construction du modèle de paramètres requis par la couche de contrôle;
• couche d'interaction de données dao: fournit les méthodes d'interrogation de données requises par la couche de service et la logique de processus liée aux conditions d'interaction de données;
• Couche de persistance du mappeur: basée sur le support natif requis par le framework mybatis, un composant de couche de persistance très couramment utilisé;

Deuxièmement, la couche de contrôle

1. Style d'interface de repos

Sur la base de la logique d'accès et de traitement des ressources, différents styles d'annotations sont utilisés. Par exemple, ajout de ressources, mise à jour, requête, suppression.

/**
 * 新增
 */
@PostMapping("/insert")
public Integer insert (@RequestBody BaseInfo baseInfo){
    return baseInfoService.insert(baseInfo);
}
/**
 * 更新
 */
@PutMapping("/update/{id}")
public String update(@PathVariable(value = "id") Integer id,
                     @RequestBody BaseInfo baseInfo) {
    if (id<1){
        return "error";
    }
    baseInfo.setId(id);
    return "update="+baseInfoService.update(baseInfo);
}
/**
 * 主键查询
 */
@GetMapping("/detail/{id}")
public InfoModel detail(@PathVariable(value = "id") Integer id) {
    return baseInfoService.detail(id) ;
}
/**
 * 主键删除
 */
@DeleteMapping("/delete/{id}")
public String delete(@PathVariable(value = "id") Integer id) {
    baseInfoService.delete(id) ;
    return "SUS" ;
}

2. Réutilisation de l'interface

Il n'est pas recommandé que l'interface soit fortement réutilisée. Par exemple, l'ajout, la suppression, la modification et la vérification de chaque interface sont suffisants. Le principe de base est que les différentes opérations client sont indépendantes de l'interface.

/**
 * 列表加载
 */
@GetMapping("/list")
public List<BaseInfo> list() {
    return baseInfoService.list(new BaseInfoExample()) ;
}
/**
 * 列表搜索
 */
@PostMapping("/search")
public List<BaseInfo> search (@RequestParam("userName") String userName,
                              @RequestParam("phone") String phone) {
    return baseInfoService.search(userName,phone) ;
}

Par exemple, dans l'interface de liste commune, la liste a généralement un mécanisme de recherche qui est chargé en fonction des conditions, et les conditions de jugement pour la recherche sont très compliquées. Il est recommandé de la diviser en deux interfaces. Pour des raisons pratiques, la plupart des scénarios n'utilisent que l'interface de liste, et rarement Utilisez la recherche pour rechercher.

3. Entrée et sortie

Vérifiez les conditions nécessaires du client, telles que certaines conditions sont requises, etc. S'il y a un problème, bloquez rapidement le lien de demande, de sorte que la couche de contrôle d'entrée de programme intercepte le retour.

@PutMapping("/update/{id}")
public String update(@PathVariable(value = "id") Integer id,
                     @RequestBody BaseInfo baseInfo) {
    if (id<1){
        return "error";
    }
    baseInfo.setId(id);
    return "update="+baseInfoService.update(baseInfo);
}

Si les paramètres sont inférieurs à trois, vous pouvez les afficher directement. Si les paramètres sont trois ou plus, vous pouvez utiliser la classe d'entité pour les encapsuler.

@PostMapping("/search")
public List<BaseInfo> search (@RequestParam("userName") String userName,
                              @RequestParam("phone") String phone) {
    return baseInfoService.search(userName,phone) ;
}

4. Traitement des paramètres

Le principe de base du degré de traitement du format de paramètre est que le serveur est une ressource publique pour éviter les opérations inutiles. Par exemple, le client peut déterminer si la valeur renvoyée est vide, nulle, etc., ou gérer certains formats courants et utiliser le client pour partager correctement la pression du serveur.

Troisième couche de service métier

1. Vérification commerciale

Par exemple, le numéro de la commande entrante est interrogé par la couche de base de données et il n'y a pas de données de commande. C'est ce qu'on appelle une exception de nature métier. Il n'y a pas de problème avec le code lui-même, mais la logique métier ne peut pas être exécutée normalement.

public InfoModel detail(Integer id){
    BaseInfo baseInfo = baseInfoDao.selectByPrimaryKey(id) ;
    if (baseInfo != null){
        DetailInfoEntity detailInfoEntity = detailInfoDao.getById(id);
        if (detailInfoEntity == null){
            LOG.info("id="+id+"数据缺失 DetailInfo");
        }
        return buildModel(baseInfo,detailInfoEntity) ;
    }
    LOG.info("id="+id+"数据完全缺失");
    return null ;
}

2. Assemblez la logique métier

Normalement, la couche de service est un élément de logique complexe, utilisé pour assembler les étapes principales de l'entreprise, et le programme peut être exécuté étape par étape grâce à des jugements de logique métier, évitant ainsi un grand nombre de requêtes de création d'objets et de données de demande possibles à l'entrée du programme.

public int insert (BaseInfo record){
    record.setCreateTime(new Date());
    int insertFlag = baseInfoDao.insert(record);
    if (insertFlag > 0){
        DetailInfoEntity detailInfoEntity = new DetailInfoEntity();
        detailInfoEntity.setUserId(record.getId());
        detailInfoEntity.setCreateTime(record.getCreateTime());
        if(detailInfoDao.save(detailInfoEntity)){
            return insertFlag ;
        }
    }
    return insertFlag;
}

3. Construction du modèle de données

En général, la couche de gestion est un peu compliquée. Si vous souhaitez comprendre rapidement la couche de gestion, vous pouvez fournir une méthode de retour à la méthode de gestion complexe pour traiter les paramètres dont la couche de service a besoin pour revenir à la couche de contrôle, de sorte que La méthode de la couche de service lourd devient plus claire.

private InfoModel buildModel (BaseInfo baseInfo,DetailInfoEntity detailInfo){
    InfoModel infoModel = new InfoModel() ;
    infoModel.setBaseInfo(baseInfo);
    infoModel.setDetailInfoEntity(detailInfo);
    return infoModel ;
}

Quatrièmement, la couche d'interaction des données

1. Rétro-ingénierie

Ici pour utiliser le framework mybatis ou mybatis-plus comme référence. S'il s'agit du framework mybatis, il est recommandé de ne pas personnaliser le code du modèle du reverse engineering. Si vous devez personnaliser la méthode, personnalisez un fichier d'extension au niveau du mappeur et du xml pour stocker la méthode personnalisée et la logique SQL, afin d'éviter les tables Fort inconfort causé par des changements structurels majeurs.

Bien sûr, la plupart d'entre eux utilisent maintenant mybatis-plus comme composant de couche de persistance, ce qui peut éviter les problèmes ci-dessus.

2. Interaction des données

En réponse aux besoins de la couche métier, fournissez les méthodes de requête de données correspondantes, ne traitez que la logique d'interaction avec la base de données et évitez la logique métier, en particulier dans l'architecture distribuée, la requête de données et l'assemblage de différents services ne doivent pas apparaître dans cette couche.

public interface BaseInfoDao {

    int insert(BaseInfo record);

    List<BaseInfo> selectByExample(BaseInfoExample example);

    int updateByPrimaryKey(BaseInfo record);

    BaseInfo selectByPrimaryKey(Integer id);

    int deleteByPrimaryKey(Integer id);

    BaseInfo getById (Integer id) ;
}

Cinq, adresse de code source

GitHub·地址
https://github.com/cicadasmile/data-manage-parent
GitEE·地址
https://gitee.com/cicadasmile/data-manage-parent

Lecture recommandée: système de programmation de finition

Numéro de série	nom du projet	Adresse GitHub	Adresse GitEE	conseillé
01	Java décrit des modèles de conception, des algorithmes et des structures de données	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆☆
02	Fondation Java, accès concurrentiel, orienté objet, développement Web	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆
03	Explication détaillée du cas des composants de base du microservice SpringCloud	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆
04	Cas complet du combat réel de l'architecture de microservice SpringCloud	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆☆
05	Premiers pas avec l'application de base du framework SpringBoot à avancé	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆
06	Le framework SpringBoot intègre et développe un middleware commun	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆☆
07	Cas de base de la gestion des données, de la distribution, de la conception d'architecture	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆☆
08	Série Big Data, stockage, composants, informatique et autres frameworks	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆☆