MODEL 기술정리

* 사내 강의용으로 사용한 자료를 Blog에 공유합니다. Spring을 이용한 Web 개발에 대한 전반적인 내용에 대해서 다루고 있습니다.

지금까지 우리는 DB에 접속을 하고, DB에 있는 내용을 이용해서 Service를 구성하는 방법에 대해서 알아봤습니다. 

기술들은 다들 자신만의 색깔을 가지고, 개발자들을 좀 더 편하게 하기 위해서 발전되어 왔습니다. 그렇기 때문에 개발자들마다 자신이 선호하는 기술들이 따로 있는 것이고요.

그렇지만, 우리가 지금까지 Model을 하는 부분에 대해서는 한가지만은 확실히 나올 수 있습니다. 

"각자의 영역으로 분리"

이것은 DB를 다루는 Model 뿐 아니라, 모든 객체와 개발에서의 Layer가 지켜야지 되는 원칙이라고 할 수 있습니다. 

일반적으로 우리가 사용한 Model은 다음과 같은 package로 나뉠 수 있습니다. 

com.xyzlast.bookstore.entities

com.xyzlast.bookstore.vo

com.xyzlast.bookstore.dto

com.xyzlast.bookstore.dao

com.xyzlast.bookstore.repositories

com.xyzlast.bookstore.services

구성될 수 있는 package에 대해서 다시 정리하고, 최종적인 web application의 데이터의 흐름에 대해서 알아보도록 하겠습니다. 

Packages

entities package

Hibernate와 같은 ORM framework를 사용하는 경우, object와 persistence model간의 관계를 구성한 ORM 객체가 위치하는 영역입니다. 또는 Table에 1:1 mapping을 해서 구성하는 경우도 있습니다. 그렇지만, entities를 사용한다는 것은 기본적으로 DDD를 사용하는 것과 동일합니다. 객체과 그 객체의 관계에 대한 구성을 코드에 녹여내는 방식을 주로 사용하게 됩니다. 

vo package / dto package

vo(value object), dto(data transfer object)의 경우에는 일반적으로 persistence model에서 넘어오는 값들을 단순 parsing할 때 사용됩니다. 여기에 가장 대표적인 기술로 mybatis를 소개하였고, 이는 db에서 얻어오는 값을 view에서 단순 표시하기 위한 방법으로도 자주 사용하게 됩니다. 

이 두 package는 myBatis를 Domain Layer의 Framework로 사용하는 경우에는 거의 필수로 사용됩니다. 또는 개발시에 Model 영역에서 Controller/View 로 데이터를 넘길때, DTO 객체를 만들어서 넘길때 사용되기도 합니다. 이때는 vo가 View Object의 의미로 사용되기도 합니다.

dao

직접 DB에 query를 보내고, entity, vo, dto를 얻어오는 영역입니다. DB를 사용하는 기술에 따라 다르게 구성이 되는 것이 일반적이며, CRUD에 대한 모음으로도 구성될 수 있습니다. 단순 CRUD가 이루어진다고 해도, DB에 대한 기술적 영역이 바뀌게 될 가능성은 항상 열어두고 작업을 하는 것이 좋을 것 같습니다. 그렇기 위해서는 interface로 정의된 dao를 사용하는 것이 보다더 효과적으로 구성이 가능하게 됩니다. dao로 지정하게 되는 것은 controller, domain 모두에서 dao를 사용하겠다는 의미입니다. Hibernate와 같은 ORM을 사용하는 경우에는 repository pattern으로 접근하는 것이 더 좋습니다.

repositories

Repository는 Dao와 매우 유사한 개념입니다. 이 두 용어의 차이점은 기능이 아닌, 사용되는 코드의 위치입니다. Domain Layer에서만 사용되는 경우에는 repository, Domain뿐 아니라 모든 영역에서 사용된다면 dao로 개발하게 됩니다. 이 둘의 차이는 Model을 풀어가는 pattern의 차이입니다. 보다더 pattern 상위적인 개념이 Repository이고, Dao는 database 적 개념이 강한 Object라고 생각하면 좀 더 이해가 쉬울 것 같습니다. 

services

business logic 영역입니다. 여러개의 dao object들과 entity 또는 vo/dto object들을 얻어내고, 그 객체들간의 로직이 구성되는 영역입니다. 일반적으로 transaction의 단위 영역이 된다는 것을 명심해주세요. 

위의 구성에서 결국은 model은 3개 이상의 package로 구성이 됨을 알 수 있습니다. 남의 코드를 보더라도 대부분 위와 비슷한 구성으로 package가 구성된 경우가 많으니 참고바랍니다. 

---

Domain Framework의 비교

다음은 지금까지 알아본 Model을 접근하는 Framework의 조합에 대해서 한번 정리해보도록 하겠습니다. 

Framework	특징	장점	단점
No Framework - PreparedStatement 를 이용하는 방법	1. Native Query 구성	1. native query를 이용한 학습 시간의 단축	1. 오타가 발생하는 경우, query를 실행하기 전까지 에러를 확인할 수 없다. 2. 중복 코드가 많이 발생된다. 3. connection의 관리를 비롯한 Transaction의 처리를 모두 수동으로 해줘야지 된다. 4. java 코드에 sql 코드가 들어가기 때문에 관리 및 debug가 힘들다.
JdbcTemplate	1. Spring JdbcTemplate 이용 2. DataSource 이용 3. Native Query	1. native query를 이용한 학습 시간의 단축 2. connection 관리 3. Transaction 관리	1. 오타가 발생한 경우, query를 실행하기 전까지 에러를 확인할 수 없다. 2. 중복 코드가 많이 발생된다. 3. java 코드에 sql 코드가 들어가기 때문에 관리 및 debug가 힘들다.
Hibernate	1. HQL, Criteria 2. DataSource 3. Spring Transaction	1. 다양한 reference 2. 객체를 이용한 query의 처리로 인하여, 코드양을 줄일 수 있다. 3. 프로그램 설계 및 구성 부분에 대해서 장점을 갖는다. (DDD와 같은 객체 지향적 구성 가능) 4. Table의 변경 또는 DB의 변경에 유연한 장점을 갖고 있다. 5. 동적 query가 자유스럽다.	1. 학습 시간의 소요 2. criteria, HQL 모두 오타에 취약한 구조 3. 단순 CRUD에 대한 코드양 증가 - 1, 2번 항목 보다는 코드 양이 적다.
Hibernate + queryDSL	1. JQL, Criteria 2. DataSource 3. type-safe 4. code generate	1. 다양한 reference 2. 객체를 이용한 query의 처리로 인하여, 코드양을 줄일 수 있다. 3. 프로그램 설계 및 구성 부분에 대해서 장점을 갖는다. (DDD와 같은 객체 지향적 구성 가능) 4. Table의 변경 또는 DB의 변경에 유연한 장점을 갖고 있다. 5. 오타가 발생할 수 없는 type-safe 한 query를 작성할 수 있다. 6. sql query와 비슷한 문법으로, 학습에 도움을 줄 수 있다.	1. 학습시간의 소요 2. 단순 CRUD에 대한 코드양 증가 2. 설정이 까다롭다.
Hibernate + JPA + queryDSL + Spring Data JPA	1. JQL, Criteria 2. DataSource 3. type-safe 4. code generate	1. JPA - java 표준 2. 객체를 이용한 query의 처리로 인하여, 코드양을 줄일 수 있다. 3. 프로그램 설계 및 구성 부분에 대해서 장점을 갖는다. (DDD와 같은 객체 지향적 구성 가능) 4. Table의 변경 또는 DB의 변경에 유연한 장점을 갖고 있다. 5. 오타가 발생할 수 없는 type-safe 한 query를 작성할 수 있다. 6. sql query와 비슷한 문법으로, 학습에 도움을 줄 수 있다. 7. CUD, select 문의 코딩양이 현격하게 줄어든다. 8. Hibernate 코드 역시 사용 가능하고 유연한 방법으로 대처가 가능하다. 9. Repository Interface code에 의한 가독성 향상 10. Spring @MVC의 @InitBinder와의 연동이 가능하기 때문에, Converter를 작성하는 시간을 줄일 수 있다.	1. 학습 시간의 소요 2. 설정이 까다롭다. 3. repository 객체를 두개를 만드는 것이 필요하다. (repository, repositorysupport)
myBatis (iBatis)	1. Native Query 2. DataSource 3. ibatis-spring 이용	1. 국내의 많은 사용자 2. sql query의 관리를 하는 것이 가능하다.	1. 객체가 아닌 VO type의 이용으로 인한, 프로그램 architecture의 발전 가능성이 낮아짐 2. java 언어 뿐 아니라, sql 로의 확장으로 인하여 관리 코드가 늘어남

출처 : http://netframework.tistory.com/entry/16-Model-기술-정리-및-비교