Only ideas worth spreading

더 좋은 웹을 위한
우리의 고민

소프트웨어 공학
MVC 디자인 패턴

WRITE윈드디자인 DATE2017.04.04 CATEGORY웹 / App 개발





 

안녕하세요. 윈드디자인입니다.

 

 

벌써 봄바람 휘날리는 노래가 여기저기 들리는 계절이 왔네요. :D

오늘은 미루고 미루던 개발 부분의 MVC 패턴에 대해 

간략하게나마 포스팅하고자 합니다.


 

이번 포스팅은 웹 개발자 및 관련 IT 분야에 대한
사전 지식이 조금은!! 필요함을 미리 알려드립니다. 

(어려운 부분이 있다면 댓글 남겨주세요. 답변드릴게요. :D) 


 


 

많은 웹사이트 제작에 있어 어떤 식으로 제작할 것인지에 대한 

기획과 설계, 그리고 어우러지게 만드는 프로그래밍은 언제나 중요합니다.

 

(안 중요한 게 어디 있겠냐만은... ㅎ)

 

MVC 패턴은 현재 많은 웹 관련 프레임워크에서 이용하는 기법 중 하나이며

모델2 기법으로 부르기도 합니다. 


모델2가 있다면 모델1도 있겠죠?

흔히 우리가 흔히 보는 웹 사이트 중 사이트 내용에 볼 단순한 내용을 자바스크립트, CSS, 데이터베이스 관련 코드 등 하나의 파일 안에 모두 추가하여 작성된 것을

모델1 방식이라 부릅니다.

 

또는 보여질 뷰(View)와 데이터베이스 관련 모델 로직만 분리한 것을 일컫습니다.

 

브라우저에 요청이 들어오면 해당 페이지는 데이터베이스 내용을 참조하여

뷰(View) 페이지에 처리합니다. 

 

무엇을 참조하였는가에 대한 정보는 각 뷰 페이지에서 확인하는 기법으로서

대부분의 웹 관련 종사자분들한테는 매우 친숙한 방식입니다.

 

이 방식이 오래되고 익숙한 만큼 이 방식을 선호하는 웹 퍼블리셔, 개발자들도 아직 많습니다.

 

 

 

하지만!! 프로젝트가 점차 규모가 확대되고 유지, 보수에 관한 사안이 들어올 때

모델1 디자인 패턴으로는 여러 한계가 있습니다. 

 

디자인 관련 코드와 데이터베이스 관련 코드가 하나의 파일에 존재하여

공동 작업이 어렵습니다.!

 


 

html 파일 안에 각종 서버 관련 언어(PHP, JSP , JavaBean)가 개입함으로써

코드의 가독성이 나빠지고 복잡함을 유발하게 됩니다.

(저희도 소규모로 시작해서 크게 와 닿지 않았으나, 점차 실감하고 있네요.... ㄷㄷ)

 

특히 PHP의 경우, 이런 경우가 심한데 

가령 상위 문서를 가져왔는데(INCLUDE) 그 상위 문서가 또 다른 상위 문서를 가져오도록 작성된 경우(INCLUDE) 등이 빈번해 코드 해석과 관리에 어려움이 존재합니다.

 

그래서 나온 디자인 패턴 이론이 바로!! MVC입니다.


 

MVC의 정의와 요소는 다음과 같습니다.
M(Model) : 컨트롤러에 의해 호출되고 데이터베이스를 조작, 반환하는 역할
V(View) : 컨트롤러에 의해 호출되고 클라이언트에게 응답할 템플릿을 보여주는 역할
C(Controller): 클라이언트의 요청을 처리, 호출, 응답을 모두 제어하는 역할.

 

 

 

예제를 통해 조금 더 구체적으로 살펴보겠습니다. 

데이터베이스에 있는 내용을 불러오는 아주 단순한 PHP 코드를 가정합니다. 

편의를 위해 PHP 클래스 및 객체 사용은 제외하도록 하겠습니다.

 

 

 

 


->test.php : 무엇 하나 분리된 것이 전혀 없는 코드 

 

현재 파일 경로명은 test.php 이며 데이터베이스 접속, 명령, 결과 반환 모두 한 페이지에 있는 경우입니다. 

페이지가 지금은 단순하기 때문에 문제가 없겠지만 매번 데이터베이스를 참조하게 된다면 이 코드는 시간 낭비이며 보안상에도 좋지 않습니다. 

데이터베이스 접속 부분을 따로 보내고 이것을 dbconn.php 라 명명한다고 가정합니다. 


 

 

->test.php에서 데이터베이스 접속 로직을 dbconn.php으로 분리 

 

 

 

데이터베이스 접속 관련 로직을 분리해 dbconn.php파일로 옮겨졌습니다. 

이로써 앞으로 데이터베이스 접속은 include 한 줄로 삽입하면 해결이 됩니다만 여전히 

데이터베이스 조작 명령어인 SQL 쿼리문이 그대로 남아있고 해당 쿼리를 수정하기 위해선 계속 뷰 페이지를 확인해줘야 합니다. 

이것을 model.php로 분리하겠습니다. 

 



 

 

->model 페이지 



 

 

-> DB접속 코드와 쿼리문이 분할된 test 페이지 

 

 

코드가 분리되어 데이터베이스를 조작하는 코드가 뷰 페이지에서 제거되었습니다. 이렇게 분리하는 것만으로도 읽기가 쉬워지며 관리하기에 있어서도 더 용이해졌습니다. 

하지만 여전히 데이터베이스 관련 로직을 모두 뷰 페이지를 기준으로 부르고 있습니다. 

 

 

이것을 제어하는 컨트롤러 페이지인 controller.php , 그리고 뷰 페이지에서 사용한 INCLUDE문을 제거하여 view.php를 만들어 보도록 하겠습니다.  


 

 

 


 

 

 

->controller 페이지  

 

 

 

 

 

 

->view 페이지 

 

이와 같이 분리하면 데이터베이스를 접속하는 로직, 데이터베이스를 어떻게 사용할까에 대한 로직, 어떤 페이지를 보여줄 것인가에 대한 로직 모두 분할이 됩니다. 만약 주소창에 type이라는 파라미터를 받고 이것에 따라 보여줄 뷰 페이지가 다르다면 이런 식으로 코드를 작성하면 각각 동적인 뷰 페이지를 전달할 수 있습니다. 

 




 

->controller 페이지 

 

물론 본 예제는 완벽한 MVC라고 볼 수는 없습니다. 실제 현업에서 절대 이렇게 단순하게 분리해서 사용하지 않으며 클래스를 기반으로 객체 지향 형태로 각각 컨트롤러, 모델명마다의 함수(Function)를 사용하여 보다 동적이며 견고하게 제작하게 됩니다 

 

 

모델이나 컨트롤러 파일도 1개가 아닌 여러 개가 되며, 실제 사용하고 있는 대부분의 웹 프레임워크는 실제 해당 경로 URL을 접속하여 페이지에 접속하는 것을 보안상 방지하고 있습니다. 

 

 

웹 프레임워크는(여기서는 PHP 기반만 언급하겠습니다.)

대표적으로 CakePHP, 코드이그나이터 , 라라벨 등이 있습니다. 

(정부 작업은 JSP의 정부 프레임워크가 기본이지요.)
 

 


 





 

MVC 패턴의 목적은 결국

코드의 재사용과 가독성, 유지 및 보수의 편이함을 위해 제안된 방법론입니다.

 

여전히 프로젝트의 규모에 따라 순간적으로 제작하기 편리한 모델 1 방식을 고수하는 경우도 많고

불필요한 파일이 늘어난다고 모델2 방식을 꺼리는 경우도 분명 존재합니다.

(실제로 아직 저희가 그러고 있습니다. ㄷㄷ)



하지만 IT 웹 관련 실무자라면 모델1 방식, 모델2 방식 및 웹 프레임워크에 대한

기본적인 이해도를 갖는다면 보다 용이한 설계 및 개발 능력을 습득하게 될 것이라 생각합니다. :D

 

 

그럼 더 나은 웹을 만드는 개발자가 많아지길 바라며!

 

 

 

사용자의 바람 에 고민합니다.
다채로운 속 집중을 통해
더 좋은 웹을 꿈꿉니다.

디자인과 기술이 융화된 디지털 서비스를 만듭니다. 

 

 



 

 


 

WIND DESIGN Co., Ltd