[JAVA] Je veux arrêter les cas de serpent avec des définitions de table

Qu'est-ce qu'une caisse de serpent?

Dans la définition de table, il est souvent défini par la casse du serpent (délimité par \ _). Par exemple, un exemple de maître qui stocke des informations utilisateur sera décrit. Nom de la table: mst \ _user

Relation avec le développement d'applications

Les langages de développement d'applications ne sont souvent pas des cas de serpent. Par exemple, dans le cas de java, il peut s'agir d'un cas Pascal et d'un cas camel.

Qu'est-ce qui ne va pas

En prenant java comme exemple, la classe (DTO) correspondant à mst_user est la suivante selon la convention Java (cas Pascal, cas Camel).

public class MstUser {
    private String userId;
    private String userName;

    // getter,setter omis
}

Bien que la table soit un cas de serpent, le mappage est nécessaire car la convention java est différente. Il y a quelques problèmes associés à cela.

1. La création de spécifications est lourde Exemple) Erreur lors de la création de spécifications d'API. Comme il y a généralement de nombreux éléments, il est facile de se tromper en copiant les éléments de la définition de la table et en remplaçant l'étui de serpent par un étui de chameau. user_id => userid => J'ai fait une erreur! En particulier, si vous ne concevez et demandez le développement que de l'extérieur, vous perdrez du temps en demandant "Et userId?"

2. C'est gênant si vous faites une erreur de cartographie pendant le développement Puisque SQL est un cas de serpent, il est nécessaire de décrire le mappage à la classe java. S'il peut être généré automatiquement par le mappeur OR, s'il s'agit d'une spécification qui se joint, le mappage sera écrit régulièrement, il y a donc une possibilité de faire une erreur. Le résultat de l'obtention de la valeur est null => Il se produit une erreur de mappage.

3. La conversion mutuelle entre la caisse de serpent et la caisse de chameau est gênante Il est lié à 1 et 2, mais il faut beaucoup de mal pour convertir cas de serpent => cas de chameau et cas de chameau => cas de serpent lors de la cartographie. C'est peut-être un peu mieux si vous fabriquez un outil, mais c'est toujours un problème.

Arrêtez les cas de serpent et adaptez-vous aux conventions du langage de développement

Suivez les conventions Java.

Nom de la table: MstUser

DTO

public class MstUser {
    private String userId;
    private String userName;

    // getter,setter omis
}

Cela vous évitera les problèmes de cartographie, vous permettant ainsi de concevoir et de développer efficacement. Y a-t-il des inconvénients?

Table des matières