Maison > Questions et réponses > le corps du texte
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 ?
高洛峰2017-05-27 17:43:05
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
ringa_lee2017-05-27 17:43:05
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. .
某草草2017-05-27 17:43:05
Pas propice au développement conjoint et à la maintenance ultérieure par d'autres
过去多啦不再A梦2017-05-27 17:43:05
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)
仅有的幸福2017-05-27 17:43:05
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 certitude
Le paramètre de retour de dao doit utiliser do/dto.
selon les exigences du document.
黄舟2017-05-27 17:43:05
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.
.黄舟2017-05-27 17:43:05
Avantages de la carte :
1、灵活性强于javabean，易扩展，耦合度低。
2、写起来简单，代码量少。
Jetez un œil aux avantages des Javabeans :
1、面向对象的良好诠释、
2、数据结构清晰，便于团队开发 & 后期维护。
3、代码足够健壮，可以排除掉编译期错误。
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 ! ~