我在项目中经常使用List<Map<String,Object>>做为查询的接受对象.感觉使用方便,不用每个多表查询的时候都创建DTO类.
上面只针对查询,如果将map应用到DTO,VO是否会有相同的问题.
光阴似箭催人老，日月如移越少年。
1、map参数数量大时不易维护。要通过识别字符串形式的key，可能哪个字母没加程序就出错了
2、map转成实体，耗费资源。或者不转实体，直接将map传到sql层，但要判断空值（传没传这个参数啊。。。），参数数量一多要加一堆判断（sql效率下降，也不易维护）
3、创建map再put进参数值，比创建一个实体类的时间要长（map数量少时创建的时间差距很小，但是数量较大时差距会非常大）
4、参数类型的控制。sql中不是字符串类型的参数还要转成数值。。。错误跑到sql中，容易被CC
5、面相对象，将sql层与实体分离，降低耦合。否则维护很麻烦
我认为有两个方面吧：1.面向对象的思想2.效率吧，毕竟玩查询的【这里的效率是指map.get(key)】,map.put然后get的 这样很容易出错吧， 的确不怎么好
都是我瞎编的，呵呵，大学老师好像讲过吧。。
不利于他人共同开发和后期维护
Map<String, Object> 类型不安全
Map用查询参数，方法调用者根本就不知道方法提供者提供方法参数可以存哪些健值对以及健值对类型，map.put(key,value)乱传的问题不能在编译阶段发现，用QueryDto可以精确定义参数类型和限制(JSR 303 Validation)
如果我没有理解错误的话.
数据查询对象是指 dao 查询方法的参数封装, 并不是指方法的返回. 这样做的好处是代码的可读性高, 你直接使用map作为接口参数, 使用者想要确定具体的查询条件非常困难, 而且给外部接口调用的灵活性太高, 比如 使用者在map中增加一个x, 但是你的查询根本不支持, 但是你如何让使用者能够确认的知道呢?
map
x
而 dao 的返回参数按照文档的要求是应该使用 do/dto.
感觉主要是调试和维护困难，比如任何key的拼写错误，要到query执行时才能反馈
map的优点：
1、灵活性强于javabean，易扩展，耦合度低。 2、写起来简单，代码量少。
看一看Javabean的优点：
1、面向对象的良好诠释、 2、数据结构清晰，便于团队开发 & 后期维护。 3、代码足够健壮，可以排除掉编译期错误。
权衡利弊，如果团队开发还是javabean比较好，个人项目就无所谓了。欢迎补充！~
1、map参数数量大时不易维护。要通过识别字符串形式的key，可能哪个字母没加程序就出错了
2、map转成实体，耗费资源。或者不转实体，直接将map传到sql层，但要判断空值（传没传这个参数啊。。。），参数数量一多要加一堆判断（sql效率下降，也不易维护）
3、创建map再put进参数值，比创建一个实体类的时间要长（map数量少时创建的时间差距很小，但是数量较大时差距会非常大）
4、参数类型的控制。sql中不是字符串类型的参数还要转成数值。。。错误跑到sql中，容易被CC
5、面相对象，将sql层与实体分离，降低耦合。否则维护很麻烦
我认为有两个方面吧：
1.面向对象的思想
2.效率吧，毕竟玩查询的【这里的效率是指map.get(key)】,map.put然后get的 这样很容易出错吧， 的确不怎么好
都是我瞎编的，呵呵，大学老师好像讲过吧。。
不利于他人共同开发和后期维护
Map<String, Object> 类型不安全
Map用查询参数，方法调用者根本就不知道方法提供者提供方法参数可以存哪些健值对以及健值对类型，map.put(key,value)乱传的问题不能在编译阶段发现，用QueryDto可以精确定义参数类型和限制(JSR 303 Validation)
如果我没有理解错误的话.
数据查询对象是指 dao 查询方法的参数封装, 并不是指方法的返回. 这样做的好处是代码的可读性高, 你直接使用
map作为接口参数, 使用者想要确定具体的查询条件非常困难, 而且给外部接口调用的灵活性太高, 比如 使用者在map中增加一个x, 但是你的查询根本不支持, 但是你如何让使用者能够确认的知道呢?而 dao 的返回参数按照文档的要求是应该使用 do/dto.
感觉主要是调试和维护困难，比如任何key的拼写错误，要到query执行时才能反馈
map的优点：
看一看Javabean的优点：
权衡利弊，如果团队开发还是javabean比较好，个人项目就无所谓了。
欢迎补充！~