저는 프로젝트에서 쿼리 수신 개체로 List<Map<String,Object>>를 자주 사용합니다. 사용하기 편리하고 모든 다중 테이블 쿼리에 대해 DTO 클래스를 만들 필요가 없습니다.
위 내용은 쿼리에만 해당됩니다. map을 DTO에 적용하면 VO에서도 같은 문제가 발생하나요?
高洛峰2017-05-27 17:43:05
1. 맵 매개변수 수가 많으면 유지 관리가 어렵습니다. 문자열 형태의 키를 식별하기 위해 문자가 프로그래밍되지 않은 오류가 있을 수 있습니다
2. 지도를 리소스를 소비하는 엔터티로 변환합니다. 아니면 엔터티를 변환하는 대신 SQL 레이어에 직접 맵을 전달하는데, null 값을 판단해야 합니다(이 매개변수를 전달할지...). 매개변수의 개수가 너무 많으면 판단이 많이 필요합니다. (SQL 효율성이 떨어지고 유지관리가 쉽지 않습니다)
3. 엔터티 클래스를 생성하는 것보다 맵을 생성한 후 매개변수 값을 입력하는 데 시간이 더 걸립니다. (맵 수가 적을 때는 생성 시간의 차이가 매우 작지만, 다음과 같은 경우에는 그 차이가 매우 커집니다. 숫자가 크다)
4. 매개변수 유형 제어. SQL에서 문자열 유형이 아닌 매개변수는 숫자 값으로 변환되어야 합니다. . . 오류는 SQL로 실행되며 쉽게 CC됩니다
5. 얼굴 객체, SQL 레이어를 엔터티에서 분리하고 결합을 줄입니다. 그렇지 않으면 유지관리가 번거로워집니다
ringa_lee2017-05-27 17:43:05
두 가지 측면이 있다고 생각합니다:
1. 객체 지향적 사고
2. 효율성. 결국 쿼리를 사용할 때 실수하기 쉽습니다. [여기서 효율성은 map.get(key)를 의미함], map.put 및 그럼 겟. 뭐, 별로 안 좋아
제가 다 만들어냈어요. 하하, 대학교 선생님이 저한테 말씀하신 것 같아요. .
过去多啦不再A梦2017-05-27 17:43:05
Map은 쿼리 매개변수를 사용합니다. 메소드 호출자는 메소드 제공자가 제공하는 메소드 매개변수에 어떤 키-값 쌍과 키-값 쌍 유형이 저장될 수 있는지 알 수 없습니다. )은 컴파일 단계에서 발견할 수 없습니다. QueryD를 사용하면 매개변수 유형 및 제한 사항을 정확하게 정의할 수 있습니다(JSR 303 유효성 검사)
仅有的幸福2017-05-27 17:43:05
제 이해가 맞다면
데이터 쿼리 객체는 dao 쿼리 메서드의 매개변수 캡슐화를 참조하며, 메서드의 반환을 참조하지 않습니다. 이것의 장점은 코드를 읽기높게 사용할 수 있다는 것입니다. 하지만 귀하의 쿼리는 이를 전혀 지원하지 않습니다. 그런데 사용자에게 확실히 알리려면 어떻게 해야 할까요?map
作为接口参数, 使用者想要确定具体的查询条件非常困难, 而且给外部接口调用的灵活性太高, 比如 使用者在map
中增加一个x
를 사용해야 합니다.
黄舟2017-05-27 17:43:05
주로 디버깅 및 유지 관리의 어려움 때문인 것 같습니다. 예를 들어 키의 철자가 틀린 경우 쿼리가 실행될 때까지 다시 보고할 수 없습니다.
黄舟2017-05-27 17:43:05
지도의 장점:
으아아아Javabeans의 장점을 살펴보세요:
으아아아장단점을 따져보세요. 팀 개발이나 JavaBeans가 더 좋다면 개인 프로젝트는 중요하지 않습니다.
추가를 환영합니다! ~