J'utilise souvent List<Map<String,Object>> comme objet récepteur de la requête dans le projet. Cela semble pratique à utiliser et n'a pas besoin de créer une classe DTO pour chaque requête multi-tables.
Ce qui précède concerne uniquement les requêtes. Si la carte est appliquée à DTO, VO aura-t-il le même problème ?
1. Il est difficile à maintenir lorsque le nombre de paramètres cartographiques est important. Pour identifier la clé sous forme de chaîne, il peut y avoir une erreur dans laquelle la lettre n'est pas ajoutée au programme
2. Convertissez la carte en entité, qui consomme des ressources. Ou au lieu de convertir l'entité, transmettez directement la carte à la couche SQL, mais vous devez juger de la valeur nulle (si ce paramètre doit être transmis... Lorsque le nombre de paramètres est trop grand, de nombreux jugements sont nécessaires). (L'efficacité SQL diminue et ce n'est pas facile à maintenir)
3. Il faut plus de temps pour créer une carte puis saisir les valeurs des paramètres que pour créer une classe d'entité (la différence de temps de création est très faible lorsque le nombre de cartes est petit, mais la différence sera très grande lorsque le nombre est grand)
4. Contrôle des types de paramètres. Les paramètres qui ne sont pas des types de chaîne dans SQL doivent être convertis en valeurs numériques. . . Les erreurs s'exécutent dans SQL et sont facilement copiées
5. Faites face aux objets, séparez la couche SQL des entités et réduisez le couplage. Sinon, la maintenance sera gênante
Je pense qu'il y a deux aspects :
1. Pensée orientée objet
2 L'efficacité, après tout, pour les requêtes [l'efficacité fait référence ici à map.get(key)], map C'est facile. faire des erreurs par .put puis obtenir, et c'est vraiment pas si bon que ça
J'ai tout inventé, haha, le professeur d'université semble l'avoir dit. .
Pas propice au développement conjoint et à la maintenance ultérieure par d'autres
Map<String, Object> type dangereux
Map utilise des paramètres de requête. L'appelant de la méthode ne sait tout simplement pas quelles paires clé-valeur et types de paires clé-valeur peuvent être stockées dans les paramètres de méthode fournis par le fournisseur de méthode. Le problème de la transmission aléatoire de map.put (clé, valeur. ) ne peut pas être découvert au stade de la compilation. Utilisez QueryD pour définir précisément les types de paramètres et les restrictions (Validation JSR 303)
Si j'ai bien compris.
L'objet de requête de données fait référence à l'encapsulation des paramètres de la méthode de requête dao, et ne fait pas référence au retour de la méthode. L'avantage de ceci est que la lisibilité. du code est élevé, vous utilisez
?map
作为接口参数, 使用者想要确定具体的查询条件非常困难, 而且给外部接口调用的灵活性太高, 比如 使用者在map
中增加一个x
directement, mais votre requête ne le prend pas du tout en charge, mais comment en informer les utilisateurs avec certitudeLe paramètre de retour de dao doit utiliser do/dto.
selon les exigences du document.On dirait que cela est principalement dû à la difficulté de débogage et de maintenance. Par exemple, toute faute d'orthographe d'une clé ne peut pas être signalée tant que la requête n'est pas exécutée.
.Avantages de la carte :
Jetez un œil aux avantages des Javabeans :
Pesez le pour et le contre : si le développement en équipe ou JavaBeans est meilleur, les projets personnels n'ont pas d'importance.
Ajouts bienvenus ! ~