미투에 적기에는 여러가지로 부적절한 글쓰기였습니다. 머;; 수정도 안되고, 글도 역순으로 달리고,,, 이럴거면 블로그에다 쓰던가 하지 말이죠… AM 02:01

사실 제가 쓰고 싶은 주제 몇가지가 다 이런 겁니다. ORM, Framework, Eclipse, 분산환경… 이딴거 재수없다고 쓰고 싶습니다. 그것도 매우 설득력 넘치게 말이죠… 쓰는건 어렵지 않을것 같은데 호소력이 있기는 쉽지 않아 보입니다. AM 01:57

front-end 가 X-Internet 기반이라 가능한 구조인지도 모르겠습니다. 그러나… 현재로서 제가 생각하는 가장 실용주의적인(요즘 유행어) 구조라고 생각합니다. 머;; 저는 그렇다고요 AM 01:54

config? 필요없습니다. URI가 말해줍니다. controller? JSP에서 transaction 관리 합니다. query XML은 필요하죠. AM 01:52

작년에 구축했던 사이트에선 이렇게 했습니다. Action JSP -> DAO -> XML AM 01:51

거기다 사이사이 들어가는 Interface 까지 하면 기능 하나 추가 하는데 필요한 파일이 6개가 넘어갑니다. 물론 이 예는 현재 진행중인 프로젝트 기준입니다. 최소한으로 줄인 겁니다. DTO 같은거 포함되면 더 늘죠. 더 줄이지는 못했습니다. framework 덕에 AM 01:50

사실 오늘 글의 요점은 하나입니다. Web Application 프로젝트에 있어서 너무 OO적인 개념으로의 접근방식의 overhead가 이제 다들 보이지 않나 하는 거지요. ActionServlet Controller DAO query XML config XML AM 01:48

그루핑의 단위를 너무 작게 잡으면 파일의 갯수가 엄청나게 늘어 납니다. 이게 생각보다 overhead가 상당합니다. 그렇다고 너무 넓게 잡으면 관리가 쉽지 않아요. conflict 도 무시 못하구요. AM 01:45

예 2) DAO :: 전에는 테이블 단위로 생성했었습니다. 그러나 형상관리시 conflict 가 너무 자주 납니다. 이젠 화면 단위 또는 서브시스템 단위로 DAO를 묶습니다. 명확한 rule을 정하기는 사실 쉽지 않습니다. AM 01:43

struts 이후에 변해버렸죠. 이제 화면 단위로 쪼갠 서블릿 보기 힘듭니다. 기능 단위로 세분화 되었죠. 그러나 어쩌면 다시 예전처럼 돌아갈지도 모르겠다는 생각이 듭니다. 유행은 다시 돌아오니까요. AM 01:38

예 1) Action Servlet :: 전에는 하나의 서블릿에서 파라미터에 의해서 분기를 해서 처리했었습니다. 당시 그루핑의 단위는 화면 단위였습니다. 조회/수정/삭제 등을 하나의 서블릿에서 분기해서 처리했죠. AM 01:15

상태를 지닐만한 아이들이 거의 없습니다. 어찌보면 Web Application 에서의 객체란 단순히 비슷한 일을 하는 메소드 들의 묶음. 관리의 편의를 위한 그루핑의 단위로 볼 수 있을것 같습니다. AM 01:13