Project Prometheus/Mapping Object ToRDB

고려해야 할 것 : 현재 만들어진 Logic Object 들 : Database 의 연동.

참조 문서 : http://martinfowler.com/isa/OR-mapping.html

대강 예측 데이터

~cpp 
    사용자 데이터
        For Login

        For Recommendation System (Read Book, point )
    책 데이터
        For Book Information
        For cauBook Information (중대 도서관시 유일한 키)
            서지번호(key), 도서관코드(ATSL)
        For Recommendation System ( Related Book Point )

ProjectPrometheus 는 RDB-Object 연동을 할때 일종의 DataMapper 를 구현, 적용했었다. 지금 생각해보면 오히려 일을 복잡하게 한게 아닌가 하는 생각을 하게 된다. Object Persistence 에 대해서 더 간단한 방법을 추구하려고 노력했다면 어떻게 접근했을까. --1002

Xper 에 O/R 맵핑 조언 구했을때 그에 대한 답변

고민할 필요 없다; 상당히 귀찮아 보이지만, 실제 전체 작업에서 차지 하는 양은 얼마 되지 않는다. 괜히 라이브러리 만들려고 하면 더 복잡해질것이다. O/R 맵핑 라이브러리로 포커스를 맞추게 되지 않도록 조심.

PEAA 의 RDB Mapping 과 관련된 패턴을 바로 적용하는 것에 대한 답변

패턴의 오/남용 문제가 발생할 수 있다. - 어설프게 아는것은 모르느니만 못한 경우가 있다. 그리고 제대로 안다고 해서 "많이" 하는 것은 정말 잘 아는게 아닐 수 있다.

한편으로 Up-Front Design Versus Evolutionary Design In Denali's Persistence Layer 의 글을 보면. DB 관련 퍼시스턴트 부분에 대해서도 조금씩 조금씩 발전시킬 수 있을 것 같다. 발전하는 모양새의 중간단계가 PEAA 에서의 Table/Row Gateway 와도 같아 보인다.

단, 이 논문을 보면 약간은 의문이 드는게

13개월 프로젝트인데 2만라인짜리라는점 - 뭐.. 꼭 소스 라인수로 세는건 무리가 있긴 하지만. Servlet 프로젝트 2만라인. 내가 전에 팀 프로젝트로 MFC 엑셀 만들때가 1만 7천라인이였는데. -_-a 물론, Refactoring 이 잘 되어있고, XP 가 잘 적용된 프로젝트이라면 적은라인수로 많은 일을 하겠지만.
초기에 UpFrontDesign 로 나간 뒤, 후기에 점진적 발전을 추구한점 - 두개가 비교대상이 되긴 어렵다.

ProjectPrometheus