I often use List<Map<String,Object>> as the receiving object of the query in the project. I find it convenient to use and do not need to create a DTO class for every multi-table query.
The above is only for queries. If map is applied to DTO, will VO have the same problem?
1. It is difficult to maintain when the number of map parameters is large. To identify the key in the form of a string, there may be an error in which letter is not added to the program
2. Convert map into entity, which consumes resources. Or instead of converting the entity, directly pass the map to the SQL layer, but you have to judge the null value (whether to pass this parameter...). When the number of parameters is too large, a lot of judgments are required (SQL efficiency decreases, and it is not easy to maintain)
3. It takes longer to create a map and then put in the parameter values than to create an entity class (the difference in creation time is very small when the number of maps is small, but the difference will be very large when the number is large)
4. Control of parameter types. Parameters that are not string types in SQL must be converted into numerical values. . . Errors run into sql and are easily CCed
5. Face objects, separate the SQL layer from entities, and reduce coupling. Otherwise, maintenance will be troublesome
I think there are two aspects:
1. Object-oriented thinking
2. Efficiency, after all, it is easy to make mistakes when playing with queries [efficiency here refers to map.get(key)], map.put and then get. Well, it’s really not that good
I made it all up, haha, I think my university teacher told me about it. .
Not conducive to joint development and later maintenance by others
Map<String, Object> is type unsafe
Map uses query parameters. The method caller simply does not know which key-value pairs and key-value pair types can be stored in the method parameters provided by the method provider. The problem of random transmission of map.put (key, value) cannot be discovered at the compilation stage. Use QueryDto can precisely define parameter types and restrictions (JSR 303 Validation)
If I understand correctly.
The data query object refers to the parameter encapsulation of the dao query method, and does not refer to the return of the method. The advantage of this is that the code is readablehigh. You can use it directly
map
作为接口参数, 使用者想要确定具体的查询条件非常困难, 而且给外部接口调用的灵活性太高, 比如 使用者在map
中增加一个x
, but your query does not support it at all, but How do you let users know for sure?The return parameter of dao should use do/dto.
according to the requirements of the document.It feels like it’s mainly due to the difficulty of debugging and maintenance. For example, any misspelling of a key cannot be reported back until the query is executed
Advantages of map:
Have a look at the advantages of Javabeans:
Weigh the pros and cons, if team development or JavaBeans is better, personal projects don’t matter.
Additions welcome! ~