iBatis가 적용된 프로젝트에 Spring까지 적용될 때 파일 변화.

iBatis만 적용했을 때 필요했던 파일 :

1. ConnectionManager.java : SqlMapConfig.xml을 불러들여 sqlMapClient를 만드는 부분을 따로 파일을 뽑았습니다.
2. UserDAO interface
3. UserDAOFactory
4. MySQLUserDAO.java : 이 부분은 UserDAO를 iBatis로 구현하기에 상당히 간단하고, MySQL에 관련한 부분이 안 보이지만 이전 프로젝트와 관련해서 보기 편하게 하려고 이름을 이렇게 붙였습니다^^;
5. UserService class


Spring까지 적용했을 때 파일들

1. 연결부는 applicationContext.xml에서 다 맡아서 하기에 따로 ConnectionManager.java를 둘 필요는 없어졌습니다.
2. UserDAO interface
3. sqlMapClientUserDao : UserDAO를 구현. Spring에서 제공되는 template로 iBatis를 연결.
4. UserService interface
5. SpringUserService : UserService를 구현. 별 내용은 없습니다. ㅡ.ㅡ 퍼시스턴스를 비지니스로.
6. UserServiceHelper : Spring에서 제공하는 클래스를 이용해서 context를 넘겨지는 역할. 비지니스 로직을 UI로.

왠지.. 스프링을 추가했을 때 비지니스 계층에 파일이 더 필요한 느낌이랄까요? 퍼시스턴스 부분까지 이미 iBatis로 간단하게 처리했기에 DAO 구현부분만 Spring class로 바꿨으니 큰 차이가 없다고 볼 수 있습니다.

문제는 스프링을 추가했을 경우, 스프링의 개념을 이해해야 하고 설정할 줄 알아야 하는데,
간단하게 적용할 수 있는 iBatis만으로도 작업량을 획기적으로 줄일 수 있는데,
만약 다른 팀원들이 스프링을 모를 경우 교육에 필요한 자원과 시간을 감수하면서 도입할 여력이 되는 가가 관건일 겁입니다.

스프링을 했을 때 추가적으로 얻을 수 있는 건
종속적인 부분을 다 설정파일에서 처리하니까 상당히 유연하게 작업이 가능하고,
트랜잭션 부분도 선언적으로 처리하는 등 여러가지 면에서 편리한 방법으로 고려할 수 있고,
로깅이나 예외처리의 반복을 줄일 수 있는 AOP를 적용할 수 있다는 정도일까요?

추후 다국적 메시지 처리나 매핑을 통한 MVC 부분의 변화도 가져올 수 있는 여지도 있고요.

위의 것도 교육과 적용하는데 얼마나 시간이 드는 가와 그만한 각오가 있는가가 중요하겠죠^^;
(빨리 끝낼 수 있다고 해도 적어도 2주 정도는 필요할텐데 구성원이 어떤 사람이냐에 따라 더 걸릴 수도 있고, 고민이 될 수도 있는 문제네요.)

(참고도서)
전체적인 틀과 서비스 부분 모양은 '스프링 프레임워크 워크북'을 참고하고,
스프링과 iBatis 연동 부분은 레퍼런스와 Pro Spring을 참고했습니다.
(제 생각에 Pro Spring은 워크북을 본 사람이라면 쉽게 접근할 수 있고, 보기 편하게 코드가 나와 있기도 하고 여러가지 인사이트를 얻을 수 있습니다.)