OOP, DataSet? 이 둘의 애증관계..

근래에 몇명의 .Net 응용프로그램을 보다가 DataAccess Layer에 관한 특이한 점을 볼수있었다.
객체지향 언어를 사용하고는 있지만 비 객체지향 프로그램을 한다는 점인데, 특별히 DataSet의 사용이 그 중심에 있는것 같다. 난 플렛폼(.Net이든 Java든)을 떠나 OO 원칙을 바르게 지켜나가는것이 중요하다고 생각한다. DataSet 사용이 왜 OO적이지 않은것인가?. 잠시 생각을 빌려달라.

DataSet은 그 자체로 하나의 객체(object)이다. 하지만 이것을 사용한다고 해서 자동으로 이를 사용하는 다른 것들이 객체지향적이 되지는 않는다. 다음과 같은 비유를 들어보자.
누군가 식당에 가서 스파게티를 주문했다고 하자. 잠시 후 점원이 가져다 준것은 스파게티가 아니라 엉뚱하게도 스파게티를 만들수 있는 재료를 그릇에 담아 준것과 비슷한 것이다. 친절한 주방장은 입맛에 맞게 직접 요리해 먹으라고 가져다 준것일 수도 있지만 배고픈 그가 정말 원한 것은 요리된 스파게티이다. 마찬가지로 DataSet은 재료를 담은 용기이지 고객에게 건내줄 최종적인 사용자 객체가 아니다.

DataSet을 최종적인 사용자에게 던저 준다는 것은 조리법을 그들에게 떠 넘기는것과 마찬가지이다. 이 말은 곧 데이터 로직을 프리젠테이션 노출한것 결과과 되고 Data-Tier와 Presentation-Tier가 커플링되어 유연하지 못한 구조가 된다. (n-Tier 원칙상 각 계층은 다른 계층에 독립적이어야 하며, Presentation-Tier는 Data-Tier를 직접적으로 접근할수 없고, 반대로 Data-Tier도 Presentation-Tier에 접근할 수 없다. 오직 중간에 계층인 Business-Tier가 이 둘 사이의 가교역활을 할 수 있다.)
이런 결과로 인한 부작용은, 프로젝트 경험이 있는 누구나가, 수도없이 겪었을 터이라 따로 말하지 않겠다.

그럼 대안은 무엇인가? 본질로 돌아가 객체지향에 충실한것이 좋은 선택이라 본다. 즉 DataSet 대신 사용자 엔터티(Custom Entity 혹은 Business Entity)를 사용하는 것이 OO 적인 이점을 충분히 누릴수 있다. 다시 말해 주문한 스파게티를 먹는 사람은 맛있게 먹어 배고픔을 달려면 그뿐이다. 고객이 스파게티를 맛있게 만드는 조리법을 익혀 스스로 만들필요가 없다는 것이다.
결국 최종 객체를 사용하는 클라이언트는 자신의 업무영역에 해당하는 문제에 좀더 노력을 집중할 수가 있어, 생산성이 향상된다.

이런 고민중에 다음과 같은 글을 보게되었다. 기나긴 가뭄끝에 만나는 단비마냥 그렇게 반가울수가 없다.
사용자 지정 엔터티 클래스 소개