MVC 패턴

 

# Today I Learned


💡 스프링 심화강의에서 역할을 따로 나누지 않고 컨트롤러에 모든 코드를 몰아넣은AllInOneController와 Controller, Service, Repository로 역할을 나눈 코드를 비교해보았다. 일단 AllInOneController 코드를 읽기 어려울뿐아니라 읽고 싶은 생각조차 들지 않았고 역할과 기능이 눈에 들어오지 않았다

💡 우선 하나의 기능을 이해하려면 모든 코드를 다 보고 파악을 해야 한다는 점과 수정을 하거나 오류를 파악하려고 할 때도 위아래로 훑어가며 해야했기에 시간도 많이 걸리고 실수도 많이 나올 것 같았다. 마치, 어떤 기관에 문의를 하려는데 업무분장이 잘 되어있어서 누가봐도 명확하게 A라는 사람이 맡은 업무구나 라는 걸 알 수 있는 것과, 도대체 이 일은 누가 하는 건지 한참을 들여다보다가 결국은 가장 말단인 것 같은 사람에게 전화해서 물어봐야 하는 상황을 보는 것 같았다.

💡 아직도 코드를 보면 머리가 어질어질하고 한참을 보고 고민해야 대략적인 그림이 그려지는데 그나마 MVC패턴을 적용해 기능별로 나누어져 있기에 이정도 그림을 그릴 수 있는 것 같다. Controller를 웨이터로, Model을 주방장으로, View를 Client가 주문한 음식으로, 손님이 음식을 주문하고 나올 때까지의 과정으로 비유한 것이 나의 초보적인 수준에 이해하기 좋았던 것 같다!

 

MVC?

• Model View Controller
• Model : 백그라운드에서 동작하는 logic을 처리한다.
• View : 사용자가 보게 될 결과 화면을 출력한다.
• Controller : 사용자의 입력처리와 흐름제어를 담당한다.

MVC Pattern?

• 어플리케이션을 Model View Controller 세가지 역할로 구분한 개발 방법론이다.
• 사용자가 Controller를 조작하면 Controller는 Model을 통해서 데이터를 가져온다.
• Controller는 받아온 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달한다.

MVC Pattern을 Web에 적용한다면??

1. 사용자가 Web site에 접속한다.
2. Controller는 사용자가 요청한 Web Page를 서비스하기 위해서 모델을 호출한다.
3. Model은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후에 결과를 반환한다.
4. Controller는 Model이 반환한 결과를 View에 반영한다.
5. 데이터가 반영된 View는 사용자에게 보이게 된다.

장점

• 유연하고 확장에 용이하다.
• 디자이너와 개발자의 협업이 용이하다.
• 유지보수 비용을 절감할 수 있다.

단점

• 기본기능 설계를 위해 클래스들이 많이 필요하기 때문에 복잡할 수 있다.
• 설계시간이 오래 걸리고 숙련된 개발자가 필요하다.
• Model과 View의 완벽한 분리가 어렵다.

MVC 패턴 흐름

손님이 식당에 들어오면 메뉴판이 보여진다.  = ( 사용자가 네이버 혹은 다음같은 홈페이지에 접속하면 뉴스, 웹툰 등 다양한 메뉴들이 보여진다.)

↓

손님이 먹고싶은 메뉴를 웨이터에게 주문한다. = (홈페이지에서 보고싶은 메뉴를 클릭하면 컨트롤러에게 요청이 전달된다.)

↓

웨이터는 주방장에게 들어온 메뉴를 요청한다. = (컨트롤러는 모델에 들어온 메뉴를 요청한다.)

↓

주방장은 메뉴를 요리한다. = (모델은 들어온 요청에 관한 정보를 처리한다.)

↓

주방장이 완성된 요리를 웨이터에게 전달한다. = (모델이 컨트롤러에 처리된 정보를 전달한다.)

↓

웨이터가 완성된 음식을 손님에게 가져다 준다. =(컨트롤러가 뷰에 정보를 전달하면 뷰는 정보를 시각화하여 사용자에게 보여준다.)