NHibernate 를 어언 4년 가까이 공부하고, 사용하면서, 처음 접했을 때의 매력(?) 에 대해 곰곰히 생각해 보게 된다. 지금이야 뭐 당연히 ORM을 쓰는게 너무나 당연하고, 왠만한 경우에도 ORM을 사용하고자 하는 관성에 젖어버려… 처음 ORM을 접하는 사람들에게 “ORM 을 공부하시고, 써 보세요. 신세계가 열립니다” 라고 말하는 것 조차 무의미하게 느껴지게 되었습니다. – 매너리즘에 젖어버렸나요?
어쨌든 다시 한번 생각해 봅시다. 아니 처음 접하시는 분들도 왜 남들이 ORM 에 많은 관심을 가지고, 개발하고, 사용하려고 하는지 생각해 봅시다.
여기 글 중에는 Microsoft 계열 즉 .NET 계열 중심으로 설명할 생각입니다. 주제가 NHibnerate 위주로 설명할 것이고, 제 경험도 Microsoft 계열에 많이 치중되어 있었기에 설명하기가 더 편합니다.
본론으로 들어가서, ORM (Object Relational Mapping) 을 쓰는 이유는 뭘까요? 우선 ORM 정의를 보면 쉽게 알 수도 있겠죠?
“Object-relational mapping' (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.”
대강 해석하면 “OOP 언어와 데이터를 다루는 RDBMS 와의 상이한 시스템을 매핑하여, 쉽게 데이터 관련 OOP 프로그래밍을 쉽게 하도록 하기 위한 기술이다” 라고 할 수 있겠습니다.
아시다시피 OOP의 class 구조 와 object-graph 는 RDBMS의 table 구조와 relation 으로 표현이 가능합니다. 다만, 이 두 가지 표현 방식에는 상당한 차이점이 있어 매핑을 통해 변환을 해주어야 한다는 점입니다.
즉 서로 다른 두 지역에서 정보 처리 방식이 전혀 다른데, 이를 중간에서 소통하게 해주는 통역기가 있다면, 둘 다 알 필요 없이, 한 지역의 정보 처리 방식만을 알면 됩니다.
그동안 OOP 언어의 현장에서의 많은 실패의 원인이 이런 데이터를 다루는 부분의 생산성의 문제에 기인한 경우가 많았습니다.
그럼 ORM 이 이렇게 통역기 역할을 해주면 뭐가 좋아지는가? 결론부터 말하면, 개발자가 OOP 및 CBD에 의한 개발에만 집중할 수 있고, RDBMS 관련 부분은 아주 쬐금만 고려하면 된다는 점입니다.
.NET 계열의 대표적인 ORM 툴인 NHibernate 의 개발 모토에도 개발에서“95%의 Database 작업을 제거하는 것이다.” 라고 했습니다.
이 말은 ORM은 OOP 언어나 CBD 개발 방법론에서 Class 나 Component 설계 및 개발에서 이질적인 RDBMS 와 관련된 부분을 최소화하고, 원 제품의 로직 구현에 충실하고자 하는 의도에서 나온 산물이다 라고 말할 수 있습니다.
그럼 실제 ORM 툴을 도입하여 제품을 개발 시에, 개발자들이 어떻게 변화하는 가를 보게 되면, DataSet과 DataTable, SQL 문을 중심으로 한 Data 와 ASP.NET Control 이나 HTML, JavaScript의 Presentation Layer 만 있는 단순 어플리케이션이 IList<Entity> 와 Repository, Validator, Interceptor 등 OOP의 다양한 기술을 동반한 한층 업그래이드된 제품으로 격상하게 됨을 느낄 수 있습니다.
특히나 RDBMS 를 전혀 몰라도 웹 개발자가 원하는 개발을 수행할 수 있다는 의미는 Data Layer와 Presentation Layer 를 자연스럽게 분리해주고, Role을 명확히 하고, 단위테스트 등 분산 개발이 가능하게 해 주는 부가 혜택도 있습니다. (물론 이 경우는 iBATIS, Dapper 같은 SQL Mapping Tool 도 제공하는 기능입니다)
자 어느정도 ORM을 왜 쓰는지에 대한 제 의견에 공감을 하시는지요? 땡기시는지요?
만약 아직 땡기시지 않는다면 앞으로 구체적으로 NHibernate 의 예를 들어가면서 ORM 의 세계에 빠져보시기 바랍니다.
물론 제가 NHibernate 를 아주 잘하는 건 아니니, 다른 견해에 대해서는 기탄없이 말씀해주시기 바랍니다. 강호에는 숨은 고수가 많으신데, 잘 나타나시질 않더군요…
댓글 2개:
그냥 지나가다 남겨요. 사실 위에 언급된 내용 과는 별로 상관없는 내용인데, ㅎㅎ
어쨌든 저는 ORM에 대해서 흔히 얘기하는 ibatis 같은 종류의 프레임 워크도 orm 에 넣고 싶네요.제 관점에서는 어쨋든 데이터 베이스를 오브젝트 즉 포조 객체에 매핑해 주는 역활을 하니까요. 어찌됫든, 제 경우에 하이버네이트나 jpa에 관심을 같는 이유중 하나는 플레이프레임 워크나 스프링 루 같은 애들이
어쨋든 jpa를 필요로 하니까 결국에 개발자과 관심을 같는 큰 부분에 개발 생산성이 있고,자동화 하기 위해서 이런것들이 현재로서는 반드시 필요하고, 그래서 관심을 가지게 되네요. 제 경우는... 별개로 어제 친구와 술자리에서 얘기를 하는데 친구의 경우는 orm 자체를 sql 매퍼 정도로 이해하더군요.자기는 도메인 객체를 해쉬맵만 쓴다고 하더라고요.orm 자체를 사용하는데 있어서도 개발자 자신이 명확한 동기를 가져야 한다고 봐요. 제 경우엔 리팩토링 공부하면서 확실히 orm이 필요하다는 것을 만이 느꼇던 거 같네요. 아무튼 ...지나가다 씀 ㅋ
댓글 쓰기