[SPRING] MVC, Service, DAO 구조에 대해

출처[펌] : http://www.cyworld.com/roykun/3099722

MVC라는 것은 Model - View - Controller의 구조를 말하는데,

Spring에서는 Model 은 db data를 가져와 메모리에 올려놓은 것이고 

View는 jsp, html 단에서 보여주는 것 

Controller는 이 두 가지를 연결해주는 것으로 보면 된다.

또한 Spring에서는 Service라는 것과 DAO라는 개념이 더 존재한다.

DAO는 data access object로 db와 소통하는데 사용하는 레이어이다.

따라서 접근하는 데이터 베이스의 변경에 유연할 수 있게 구현부와 선언부를 나누어 놓는 것이 좋다.

Service에 관련한 이해는 위키피디아에서 확인하는 것이 좋은데, SOA라는 아키텍쳐와 연관된 개념이다.

예를 들면, 로그인 서비스, 검색 서비스, 이메일 서비스 등과 같이 독립적인 로직을 갖는 처리 단위로 보면 될 것 같다.

View와 Controller의 역할은 명확하다.

View는 유저에게 노출되는 화면(UI)이고 

Controller는 이런 View에게 Model이라는 데이터를 건네주거나 View로부터 입력을 받아 Model을 변경하는 중간자 역할이다.

그렇다면 Model은 무엇일까? DB data와는 무엇이 다를까?

Model이 DB와 다른 점은 DB의 데이터는 하나의 개념으로 묶이는 데이터가 여러 table상에 존재할 수 있다는 점이다.

table의 크기가 너무 커져버리면 퍼포먼스상에 큰 문제가 발생할 수 있기 때문에 DB는 데이터를 적당한 단위로 잘라서 가지고 있다.

그리고 이러한 데이터들의 연관성을 id를 두어서 지어주고 이를 index로 활용하여 검색을 빠르게 만드는 것이 보통이다.

하지만 db에서 뽑아온 데이터를 편하게 사용하려면 하나의 개념에 맞게 모여야만 한다.

예를 들면 Customer라는 개념이 있다. 그리고 Customer의 이름, 주소, 전화번호와 같은 데이터와 이 Customer가 여태것 구매한 목록이 있다.

이름,주소,전화번호와 같은 개인정보를 다루는 table과 customer의 구매목록을 다루는 table은 별개로 존재한다.

하지만 Model은 이와 같은 table들을 조합하여 하나의 개념으로 구성되어야만 편리하게 사용할 수 있다.

그럼 이러한 Model의 구성은 어디서 해야하는 것일까?

이 부분이 바로 Service와 DAO의 역할을 결정하는 중요한 지점이다.

(이 부분부터는 개발자의 생각에 따라서 유연하게 결정해야할 문제인 것 같다.)

일단 내가 세운 원칙 중 하나는 DAO에서 데이터를 받아오는 각 함수들은 반드시 Model을 return해 주어야 한다는 것이다.

그것도 완벽하게 모든 field를 채운 model을 주는 것이 좋다.

다만, 속도의 문제를 위하여 일부만 포함한 model을 주어야 할 경우가 있을 수 있다.

혹은 대부분의 경우 사용하지 않는 field는 제외하고 채워서 건네줄 수도 있다. ( 이 부분은 유연하게 각자 알아서 )

이렇게 하면 db의 종류가 변경되더라도 같은 형식으로 data를 건네주기가 용이하고 따라서 Service를 변경할 필요가 없다.

그렇다면 Service 레이어의 포지셔닝은 어떻게 해야할까.

물론 그 고유의 포지셔닝(로그인, 이메일 등의 처리 단위로서의 역할)은 아직 존재한다.

여기서 고민되는 부분은 그저 모델을 얻기위하여 존재하는 경우이다.

이 경우는 일단 대부분의 경우 bypass가 되는 것이 맞다고 생각한다.

하지만 그렇다고 아예 이 부분의 역할이 없는 것은 아니고,

DB에서 모델을 얻어오고 나서도 뭔가 데이터에 변경이 필요한 경우 Service 레이어를 이용하면 좋을 것 같다는 생각이 든다.

예를 들면, Model이라는 하나의 독립적인 개념으로 구조화 될 수는 없지만 Controller에서 사용하기 용이한 형태로 가공해야하는 경우가 있을 수 있다.

그래프를 위한 데이터를 만들어야 한다고 생각해보았을때, 그래프를 위하여 필요한 Model의 개념은 여러가지이다.

만일 Customer의 구매량의 그래프를 생각해본다면, Customer의 구매목록에서 구매 물품이라는 Model을 찾을 수 있을 것이다.

그리고나서 구매 물품이라는 Model에서 구매 시기를 가지고 온 후, 이를 재조합하여 그래프를 구성해야할 것이다.

이러한 데이터의 흐름을 전체적으로 보면 

db -> (DAO) -> Model -> (Service) -> Model for Controller

db -> (DAO) -> Model : db의 데이터가 DAO를 통하여 Model이라는 새로운 개념으로 구조화된다.

Model -> (Service) -> Model for Controller : 대부분의 경우 Service는 없는 것과도 같지만 Model을 Controller가 원하는 형태로 가공하여 전해줄 수 있다.

원래 MVC에서는 Controller가 Model의 가공을 담당했을텐데 Spring에서는 Service라는 객체가 있어서 Model - View Connection의 역할과 Model의 2차 가공 역할을 분리하게 된 것 같다. ( 아이폰 프로그래밍의 MVC에서 Controller를 나는 이렇게 활용했었다 )

음, 근데 이글을 적다보니 정말 내가 MVC를 잘 이해하고 있는 것인지 의심이 들기 시작한다.

맘 같아서는 MVC관련 서적을 좀 읽어보고 싶은데...

개발자들에게 공부할 시간은 정말 사치로구나... 특히나 오픈을 앞둔 프로젝트 개발자라면 ㅜㅜ

Spring 서적도 MVC 서적도 제대로 읽어본 일이 없이 이렇게 정리하는 것은 위험할 것이지만...

그래도 이렇게라도 정리해놔야 나중에 고치더라도 잘 고칠 수 있을 것 같다.

일단은 이런 형식으로 구현해 나가도록 하자.