먼저 MVC패턴을 소개하기 전에 앞서 디자인 패턴에 대하여 짚고 넘어가자
디자인 패턴이란
클래스 구조를 갖는 프로그래밍을 하다보면 클래스간에 구조가 짜여지고 다양한 방법으로 객체가 생성되며 관계에 따라 여러가지 형태의 행동들이 나타난다. 그런데 기초 설계가 제대로 되어있지 않은 상태로 프로그래밍이 시작된다면 얼마 못가 클래스 관계가 꼬일대로 꼬여 누더기 진흙탕 코드덩어리로 변하게된다. 엄청나게 뛰어난 사람이어서 초기 요구에 맞춰 잘 짜여진 클래스관계를 만든다 해도 요구 사항이 바뀌게되면 쉽게 대응하지 못한다. 이미 갈 때 까지 간 코드를 뒤엎는건 그만큼 큰 비용을 감수해야하는 행동이다.
그런데 Object oriented programming은 이게 아니지 않은가? 분명 클래스 구조의 프로그래밍을 했는데도 프로젝트가 진행되다보면 데이터의 은닉과 캡슐화, 코드의 재사용성과 확장성 등은 누더기 코드에 가려 보이지 않는다. 제대로된 OOP를 하지 못했다는 이야기이다. 그렇다면 제대로된 OOP란 무엇을 말하는것인지 의문이 생긴다. 많은 사람들이 이에대해 고민했고 프로그램의 목적이 어떻든간에 프로그램안에 클래스들이 갖는 구조에는 일정한 '형태' 혹은 '패턴' 이 존재한다는 것을 인지하기 시작했다. 이를 바탕으로 클래스간의 관계, 클래스간의 행동양식을 분류하고 각각에 대해 객체지향적인 설계를 따르는 노하우들이 차곡차곡 정리되어 객체지향적으로 합당한 클래스 설계 형태를 정립하기 시작했고 이를 클래스 디자인 패턴 이라 이름붙이게 되었다.
클래스 디자인 패턴은 "'이러한 상황' 이라면 '이러한 형태의 클래스 디자인'을 하는게 대게 좋더라" 라고 말해주는것이다. 프로젝트 규모가 커지고 협업 인원이 많아질수록 이러한 기준은 일을 효율적으로 처리할 수 있게 만들어준다. 하지만 주의해야한다. 표준화된 작업은 여러가지 상황을 고려하며 만들어지기 때문에 대체로 효율성이 떨어지기 마련이다. 또한 패턴간의 관계를 생각하지 못하면 설계를 복잡하게 만드는 요소가 되어버린다. 그렇기 때문에 클래스 설계자는 분류된 디자인 패턴의 사용 목적, 장단점, 강점과 약점에 대한 충분한 이해와 패턴간의 융합에 발생할 수 있는 문제점들을 확실히 예상할 수 있어야 하며 이를 바탕으로 디자인 패턴을 적용해야한다. 무분별한 패턴의 남용은 오히려 프로그램을 망치게된다.
참조: http://alleysark.tistory.com/197
정리하자면 우리가 프로젝트를 진행함에 앞서 무작위로 개발을 진행해 유지보수가 엉망인 코드, 비효율적인 코드를 만들기 보다는 디자인 패턴 즉, 상황 별로 대처해야할 만한 메뉴얼을 제시하여 이러한 방향으로 개발을 설계형태를 제시해주는 것이 디자인 패턴인 것 같다.
디자인 패턴에는 여러가지 종류가 있는데 오늘을 그중에 MVC 패턴에 대하여 설명하도록 하겠다.
MVC = Modeling + View + Controller 의 공식을 가지고 있는 패턴이다.
기본적으로 객체지향 언어를 이용한 프로그램에서는 필요한 기능에 대해 별로의 클래스를 만들어 이용하는데
Modeling 의 역할을 하는 클래스 (비즈니스 로직 처리 담당 클래스)
View 역할을 하는 클래스 ( 페이지 출력 ex JSP )
Controller 역할을 하는 클래스 (
로 나누는 것이 핵심이다.
이렇게 각각의 역할을 하는 클래스는 독립적으로 작동하는 것이 아니라 서로 연관관계를 맺으며 프로그램의 목적된 바를 수행하는데 여기서 핵심은 연관관계를 최소화 시키는 것이다.
연관관계를 최소화 시킨다는 것은 유지보수와 재사용성이 큰 장점을 준다.