나는 그동안 MVC패턴이란 말은 정말 많이 들어봤지만, 실제로 패턴 방식을 사용해 본 경험도 적고 일일이 신경써서 해야한다는게 솔직하게 귀찮아서 ㅎ 그동안 공부해오지 않았다.
그러다가 회사에 들어가 프로젝트를 진행하면서 MVC 패턴을 사용할 수 있는 기회가 왔고, 마침 옛날 부터 공부하고 싶었기에! 내가 공부한 내용을 이 글에 공유하려 한다.
MVC 패턴을 디자인 패턴이라 하는데 디자인 패턴은 무엇을 의미하는 것일까?
초보 개발자는 패턴이라 하면,,
이런게 먼저 떠올릴것이다 ㅋㅋㅋㅋㅋ
하지만 여기서의 디자인 패턴은 저런 패턴도 아니고 그렇다고 코드도 아니며
소프트웨어의 디자인 패턴은 문제에 접근하여 해결책을 찾는 방법을 설명하는 것과 같다.
MVC 패턴이란?
다들 한번쯤은 MVC패턴이란 말을 들어보고 그의 따로 약자로 model, view, controller라는 것까지는 알고 있을것이다.
외의 것을 설명하자면 간단히는
어플리케이션을 3개의 영역으로 분활하고 각 구성요소에게 고유한 역할을 부여하는 개발방식이라고 말할 수 있다.
마치..
그럼 이제 MVC 패턴이 어떤 것을 하는지는 대충 감을 잡았을 것이다. 이젠 MVC 패턴의 구조를 살펴보면서 각각의 컴포넌트가 어떤 역할을 하는지 알아보자.
MVC 패턴 구조
MVC는 3개의 컴포넌트로 이루어져있다.
먼저 model, view, controller중 model에 대해 알아보자
Model (모델)
- 데이터, 정보들의 가공을 책임지는 컴포넌트
모델은 어플리케이션의 정보, 데이터를 나타낸다. 데이터 베이스, 처음의 정의하는 상수, 초기화 값, 변수 등을 뜻한다.
비즈니스 로직을 처리한 후 모델의 변경사항을 컨트롤러와 뷰에게 전달한다.
View (뷰)
- 사용자에게 보여지는 부분, 즉 유저 인터페이스를 말한다.
MVC 패턴은 여러개의 뷰가 존재할 수 있고, 모델에게 데이터를 전달받는다.
단! 모델에게 전달받은 데이터를 별도로 저장하지 않아야 한다.
왜냐 뷰의 역할은? 유저 인터페이스! 이기 때문에 사용자가 화면에 표시된 내용을 변경하게 되면 모델에게 전달하여 모델을 변경해야하기 때문이다.
Controller (컨트롤러)
- 모델과 뷰 사이를 이어주는 브릿지 역할
모델이나 뷰는 서로의 존재를 모르고 있다.
변경사항을 외부로 알리고 수신하는 방법만 있다. 컨트롤러는 이를 중재하기 위해 모델과 뷰를 알고 있어야한다.
사용자가 어플리케이션을 조작하여 발생하는 변경이벤트를 처리하는 역할을 수행한다.
MVC 패턴을 왜 사용해야할까??
결론 : 유지보수
최초 설계를 아무리 꼼꼼하게 한다고 보장을 해도 언젠가 다시 유지보수를 하는 날이 올때면 각 기능간의 결함도가 높아지는 경우가 발생한다.
결함도가 높아진 시스템 자체는 유지보수할때에 다른 비즈니스 로직에 영향을 미치므로 사소한 코드더라도 의도치 않은 버그가 발생 할 수 있다.
이러한 경우를 대비하기 위하여 우리는 지금까지 많은 사람들이 MVC 패턴을 사용하고 있다.
MVC 패턴의 장점
MVC 패턴을 도입하면 도메인 영역과 UI영역이 분리되므로 서로 영향을 주지 않아 유지보수하기 용이하다.
MVC 패턴 구조를 가진 시스템의 각 컴포넌트는 자신이 맡은 역할만 잘 수행한 후 다른 컴포넌트로 결과만 넘겨주면 되기 때문에
시스템 결함도를 낮출 수 있다.
유지보수시에도 특정 컴포넌트만 수정하면 되기 때문에 쉽게 시스템 변경이 가능하다.
정리 :
화면 변경 시 -> view
데이터, 비즈니스 로직 -> model
뷰와 모델 변경에 따른 일부 컨트롤러 변경 -> controller
이렇게 MVC 패턴에 대해 조사하고 공부하다 보니 문득,, MVC 패턴 창시자가 궁금해져 검색해 보았다.
MVC 패턴 창시자는 다름아닌 트리베 린스카우그로 제록스 팰러앨토 연구소 에서 연구되어 1979년에 최초로 소개 되었다.
이 팰러앨토 연구소에서는 이더넷, GUI, 객체 지향 프로그래밍 등을 개발한 곳으로 굉장한,,, 곳이였다.
그래서 MVC 패턴 또한 객체지향과 GUI 방식을 섞어 만들거라고 할 수 있다. 당시 앨런 케이가 창시한 객체지향 프로그래밍에서
계속 그는 생각하였다.
좋은 코드를 만들기 위해서,
어떤 방식으로 코드를 나누고 묶어줘야 할까?
어떤 방식으로 코드를 추상화해야할까?
여기에 대한 앨런 케이의 답은 '객체'라는 단위들이 '메시지'를 주고받는 형태로 소프트웨어를 추상화하자는 것이였다.
트라이브는 여기서 한 발 더 나아간다.
트라이브가 GUI를 사용하는 애플리케이션을 잘 보니, 'UI 관련된 코드'와 '데이터 저장/처리 코드'는 특성과 하는 일이 뚜렷하게 달랐다. 변경하는 이유나 시점도 무척 달랐다.
트라이브는 (1) '비즈니스 로직'과 (2) '시각적인 UI' (3) 둘 사이를 연결해주는 부분을 코드 안에서 분리하고 역할 부여를 해줘야 한다는 생각을 하게 된다.
그래서 우리가 알게된 MVC 패턴이 탄생하게 된것이다..
댓글