그거슨 스르러츠에서 request를 자동으로 object으로 넘겨주는 기능이 없어서 막 Map을 썼는데, 이게 쓰다보니 편하단 말죠. class안마들어도 되고, 이거가지고 여기저기 열심히 넘어들어가는거지요. 음핫 도대체 누가 첨에 이짓을 시작했는지 잡히면 둑음. 아무래도 S사 에서 먼저 시작한짓이 아닐까 사료됨

근데 어쩜그리 여기랑 똑같네요--;

나름 똑똑하게 일한다는 사람들인데 이렇게 되어 있어서 잠시 황당한 상황인데... 이걸 어떻게 말하나... 상처입지 않을까? -_-

N사에서 iBatis 발표한 자료를 보니깐 Map이랑 custom 클래스랑 별 상관이 없다고 하던데.... 그럼 어떻게 해야되는건가요? 저도 iBatis 랑 아파치 DBCP랑 같이 쓰는 중인데.... 전 잘 상처 안 입는 편이에용. ㅋ

참고로 전 서블릿은 안 쓰지만, request의 parameter를 각각의 handler가 처리하고, handler가 dao를 호출하면 iBatis가 결과를 받고, 다시 handler에게 넘기는 구조인뎅.... 복사는 잘 몰르겠습니다. ^^;

지원 : 음... iBatis에서 Map을 쓰기 때문에 문제인게 아니고요. 쿼리에서는 id 값만 받으면 되는데 무조건 모든 servlet parameter를 map에 몽땅 복사하고 그걸 서비스 레이어 DAO 레이어로 전달 전달한 후 ibatis에 바로 넣어버린다는 거죠. 서비스랑 dao는 id 값만 하나 파라메터로 받아서 이것을 ibatis에 사용하는 식으로 해야 하는데 말이죠.

그렇군요 그럼, 저는 id 값만 전달하고 있으니 맞는 것 같군요. 다행이다. 하아..... ^^;

요청당 페어로 커스컴 객체를 만드는게 맞는걸까요? 종종 Map(RequestParameters/Data) 와 Validator을 받는 객체 한두개(상황마다 다르게 구성된) 으로도 .. (응?;;;)

ㄴ 써 보니까 말이 안되는 듯 하네요. ㅎㅎㅎ 걍 에러 안나고 성능 좋으면 뭐든 되죠.뭐. ㅋㅋ

ㄴ 문제는 맘 편하게 아무렇게나 코딩해도 에러 안나고 성능 좋게 되지 않으니 문제지... 무엇보다 신경 써야할 것은 유지보수성이니...

ㄴ그리고 무조건 Map이라서 문제인 것도 그렇다고 무조건 객체에 담으면 괜찮은 것도 아니겠지... 언제나 trade off는 있는 것이니 상황에 따라서 알 맞은 것을 써야... 여기의 문제는 단지 id 인자 하나면 되는 곳에도 map으로 처리 했다는...

ㄴ 아마 그 컨트롤러는 여러 데이터를 받다가 ID만 받게 수정되고 수정되었던것 아닐가요? ㅎㅎㅎ

ㄴ 모든 서비스의 메소드 인자가 Map이라니 내가 이러지. 어느 것 하나 때문이 아니라. 사람들에게 물어봤더니 그렇게 쭉 해왔다네.

역시 그렇게 쭉 하는게 쵝오. 사실 덜도 말고 더도 말고 딱 필요한 것만 넘기고 받고 싶어요 라는

일관성있고 좋네요. ㅋㅋㅋ

이 사람들에게 어떤 교육을 해야할지 고민 중. SOLID 원칙과 필수 디자인 패턴 서너개?