TDD Pattern (2)
TDD-Pattern 2
MVC 아키텍쳐
MVC 아키텍처는 웹 애플리케이션을 모델-뷰-컨트롤러(Model - View - Controller)라는 세 영역으로 나누어 구성하는 것이다.
시각적인 요소를 갖고 있는 웹 애플리케이션의 표현 영역을 뷰라 부르고, 업무로직과 데이터를 묶어서 모델이라고 부른다. 그리고 뷰와 모델을 중간에서 중재해주는 역할을 컨트롤러가 책임진다. 뷰는 컨트롤러하고만 대화하고, 모델도 마찬가지로 컨트롤러하고만 대화하는게 원칙이다. 이때 대화의 매개체로 DTO가 종종 사용된다.
MVC의 장점
- 표현(View)과 로직(Model)의 느슨한 결합(loose coupling)
- 관심의 분리
- 테스트 주도 개발 작성이 좀 더 용이함
- 각 영역에 대한 재사용성이 높아짐
결과적으로 변화에 대한 적응성이 높아지기 때문에, MVC 아키텍처를 많이 사용한다.
뷰
뷰(view)는 웹 애플리케이션의 사용자와 직접적으로 대화가 이뤄지는 부분이다. 웹 애플리케이션 측면에서는 HTML, JSP, PHP, ASP 등에 해당한다. 뷰는 사용자의 동작과 연관되어 있는 부분이 많고, 비교적 자주 변경되는 부분이라 웹 애플리케이션 개발에서 많은 시간이 소요되는 영역이다. 때문에 뷰를 TDD로 개발하려면 쉽지 않다. 그리고 뷰에는 다양한 요소들이 혼재되어 있다. 그럼에도 보통은 이를 분리해서 생각하지 않고 뷰라는 한 가지 개념으로만 접근하기 때문에 더욱 어렵게 느껴지기 쉽다.
뷰에 대한 TDD 적용은 매우 까다롭고, 유지보수 시 변경 작업도 잦은 편이라 ROI가 잘 나오는 작업은 절대 아니다. 굳이 TDD를 적용한다면, 보통은 HTML 폼 필드들과 사용자 액션 위주로 작성하게 된다. 웹 페이지 내의 이벤트는 자바스크립트가 흔히 사용되는데, 이때는 JsUnit 같은 자바스크립트 기반의 테스트 라이브러리를 사용한다.
컨트롤러
컨트롤러(controller)는 모델과 뷰를 분리하기 위해 사용되는 중간 층이다. 뷰로부터 넘어온 요청에서 데이터 모델을 발췌해서 적절한 모델 쪽으로 넘겨주고, 모델로부터 받은 응답을 다시 뷰로 돌려준다. 뷰 입장에서는 컨트롤러만 알면 되고, 모델 입장에서도 컨트롤러만 알면 된다. 모델과 뷰를 재사용할 수 있게 해준다는 부가적인 장점도 만들어준다. 앞에서 뷰에는 TDD를 적용하기가 어렵다고 말했는데, 그럼 컨트롤러 작성시 TDD를 적용하는 것은 어떨까? 결론부터 이야기하자면, 컨트롤러에 대한 TDD 작성은 비교적 수월하다. 요청으로부터 적절한 데이터를 발췌해내고, 해당 데이터를 모델로 넘긴다. 다시, 그 결과로 모델로부터 받은 데이터를 응답에 담아서 뷰로 넘기는 구조가 가장 기본적이다. 요즘은 웹 애플리케이션 개발을 할 때 소위 말하는 프레임워크 없는 날코딩을 하는 경우가 매우 드물기 때문에, 컨트롤러를 직접 만들 일은 없다.
모델
MVC에서는 모델(model)과 뷰를 완전히 분리하는 방식으로 작성할 것을 권장한다. 모델이 통신하는 컨트롤러와의 관계도 사실 자세히 살펴보면 모델이 컨트롤러를 호출하는 경우는 없다. 모델은 오로지 무언가의 호출에 응답할 뿐이고, MVC 모델의 웹 애플리케이션에서는 컨트롤러가 모델을 호출하는 역할을 맡고 있을 뿐이다. 혹자는 이런 방식을 객체 지향 원칙 중 하나인 헐리우드 법칙(Don’t ask me, I’ll tell you)8이라고 부르기도 한다. 모델에 대한 TDD는 앞에서 계속 이야기했던, 일반적인 애플리케이션을 작성하던 방식대로 TDD를 진행하면 된다. 웹 애플리케이션 구성요소 중 가장 TDD가 쉽게 적용되는 부분이고, 또 적용해야 하는 부분이다.