ologist`s story

////////생략
               Vector v = new Vector();
               ResultSet rs = ps.executeQuery();
               while(rs.next()){
                       TestVo eb = new TestVo();
                       eb.setName(rs.getString("NAME"));
                       eb.setAge(rs.getInt("AGE"));
                       v.addElement(eb);
               }
        ///////////////// 생략
              return v;

저희 들이 만든 클래스가 다음과 ResultSet2 라고 하면..
위의 코드는..
            ////////생략
               ResultSet rs = ps.executeQuery();
               ResultSet2 rs2 = new ResultSet2(rs) ; //
               return rs2;

출처 : 자바서비스넷

위에 있는 코드를 한번 더 사용을 하겠습니다. ResultSet을 리턴하는 코드가 데이터 populate하는 코드가 없어서
무척 간결해 보입니다. 이 부분만 보면, 일단 후자가 훨씬 좋은 방법처럼 보입니다.

하지만, 데이터를 사용할때 문제가 발생할 수가 있습니다.
먼저 코딩하는 사람의 입장에서 rs.getString("NAME") -> 요렇게 데이터 값을 가지고 옵니다.
만약에 필드이름을 미스 타이핑해서 사용을 한다면, 컴파일시 절대 에러가 나지 않습니다.
(Map을 사용해도 마찬가지고요) 하지만, VO를 사용한다면, 그 안에 데이터형타입이나 자료구조 자체가 하나의
API이므로, 그 객체의 성질을 쉽게 알수 있습니다. 예를 들어서 이클립스에서 코드 자동완성(ctrl+space) 기능을 사용한다고 해보면
rs.을 찍고 나면 어떤 API들이 나옵니까? rs.getString으로 사용을 하거나 아님 메타데이터를 얻어와서 처리를 해야 합니다.
그러나, VO를 사용한 객체라면 vo.을 찍는 순간 사용가능한 api들이 나옵니다.
이 두가지의 차이의 의미를 곱씹어볼 필요가 있을듯합니다. 어떤 코딩방식이 버그를 덜 발생을 하는지?
견고한 코딩이라면, 가장 빠른 진입점에서 체크가 가능해야 할 것입니다. 그래서 귀찮지만, 유효성체크를 하는 것이고요.

DAO에서 BO에 자신의 메소드를 서비스할때 BO에서 사용하기 좋게 만드는 것이 DAO 자신이 편한 것보다 더 나은 코딩이 아닌가 생각합니다.

그리고, J2EE 레이어 패턴 관점에서 보면, 레이어간에 통신은 인터페이스가 가장 느슨한 결합을 만든다는 것은 모두들 아실겁니다.
레이간에 데이터 구조가 만나는 순간은 POJO(?) 객체를 사용하는 것이 좋다는 생각이 듭니다.
예를 들어서 반대로 생각해보면 view단에 request,response가 DAO까지 넘어가는 모습은 어떻습니까?
그와 마찬가지로 레이어(DAO, BO, Action, JSP 등등) 간에 데이터를 이동할때는 가급적 종속적인 API를 사용하지 않는것이 복잡도를
떨어뜨릴수 있고, 좀더 향상된 패턴이라고 생각을 합니다.

조금 편해보고자 사용했던 종속적인 API들이 유지보수나 확장을 할때 발목을 잡기도 합니다.
EJB가 아니고 POJO J2EE를 할때도 best practice 프로그래밍 모델은 크게 다르지 않다고 생각을 합니다.

두서없이 글을 썼는데 정리를 하자면,

1. 가급적 레이간에 API종속을 만들지 말자(Resulset, request & response)
- 최근에는 자동으로 populate를 해주는 API들이 많이 나와서 과거처럼 setXX를 많이 사용하지 않아도 원하는 자료구조로 쉽게 만들수 있습니다.
- 범용적인 데이터타입으로 코딩을 하자.
ex) 자카르타DBUtil, BeanUtils, webwork filter/interceptor etc

2. 레이어간에 통신은 가급적 인터페이스를 사용해서 커플링을 줄이자.

3. name/value쌍으로 되어 있는 구조가 항상 좋은 형태는 아니고, 더 많은 코딩이 필요할수도 있다.
데이터를 만드는 관점만을 보지 말고, 사용하는 관점도 생각을 해야 합니다.

4. 사람과 기계(machine, tools)가 잘 알수 있는 코딩을 하자. 가장 빠른 타임에 형타입을 분명히 해서 버그나 오류를 최소화 하자.
- 이클립스에 코드완성 기능은 miss타이핑도 막을수 있고, 최소한의 api문서를 보고 개발이 가능하게 합니다.

5. VO vs ResulSet vs Map

-. VO 일반적으로 사용하는 패턴

• SUN은 VO(Transfer Object)를 사용을 권유
• 어떤 서비스를 하던간에 재사용이 가능한 객체(웹서비스,RPC, REST, BO, Action, JSP 등등)
• OOP의 중요 특성중 하나인 캡슐화 가능
• 수동populate
• 수많은 VO관리의 어려움

-. ResultSet :

• JDBC API종속적
• 클라이언트에서 JDBC API를 알아야 한다.
• 리소스관리 및 예외처리가 어렵다.(비용이나 코딩량이 만만치 않다.)
• 런타임시 에러나 버그는 DAO와 BO는 모른체 클라이언트만 알수도 있다.
• 인터페이스가 무엇을 말하는지 두리뭉실 알 수 없다.

- Map :

• ResultSet보다는 나은 데이터구조라고 생각을 한다.
• 프러퍼티들을 가지고 올때마다 부담스런 casting을 해야 한다.
• composite object관리의 어려움( Map안에 Map안에 Map?)
• 가독성이 떨어진다.
• 별도의 API문서화 필요
• 캡슐화X
• 인터페이스가 무엇을 말하는지 두리뭉실 알 수 없다.

클라이언트에 서비스하는 객체형태를 우선순위를 두자면, VO > Map > ResultSet으로 점수를 주고 싶습니다.

사실 비즈니스 로직에 따라서 선택을 해야 하는 부분도 있습니다.
그런 어쩔수 없는 경우는 Resultset보다는 Map형태가 더 나은 방법이 아닌가 생각합니다.
ResultSet은 가급적 지양하고, VO와 Map을 섞어서 쓰는 형태로 개발하는 것이 좋을 듯합니다.

개발자들 여러명 모아두고 한달을 얘기해도 끝나지 않을 이야기 같지만, 선택은 항상 개발하는 사람 본인이 하는 것입니다.

여러 사례들을 참조해서 자신만의 best practice 프로그래밍 모델을 만들어 가시길 권합니다.

형식 안전성(type-safety)에 지장 : String을 매개변수로 전달할 경우, 런타임 오류발생 가능성 크다