세미나를 진행하면서 부족하지만 그래도 쎄가리만바리 빠지게 준비를 했다.
기억력의 휘발성이 강해서 까먹기전에 기록을 해야겠다.
분명 틀린부분도 있을텐데 한 번 정리하고 끝낼게 아니고 계속 공부를 할 것이기 때문에 수정을 할 것이다.
🐔 디자인 패턴
- 디자인 패턴은 소스코드나 개발에 필요한 리소스를 어떤 방식으로 구조를 만들고 사용할 지를 말하는 것이다. 개발을 계속 진행하게 되면 자연스럽게 규모가 커지는데 유지보수의 불편함을 느끼게 된다. 이 불편함을 최소화 하기 위해서 디자인 패턴을 적용하는 것이다. 디자인 패턴은 많은 종류가 있는데 이는 개발자들이 자신의 프로젝트의 구조를 어떻게 짜냐에 따라 달라지기 때문이다.
🐤 MVC의 역사
- MVC패턴의 역사를 알아보면 1979년 노르웨이 컴퓨터 과학자 트리베 린스카우그(trygve reenskaug)가 고안한 디자인으로 제록스 팔로알토 리서치센터의 smalltalk-80이라는 논문에서 처음으로 채택되었다. 이후로 웹 프레임워크에서 많이 사용되기 시작한다. 오래전 개발자들은 이러한 패턴들이 없었을 때에 마음대로 프로그램을 구성하여 개발을 했지만 유지보수나 협업을 하는 과정에서 큰 불편함을 겪었고, 이를 해결하기 위해 수많은 패턴들이 시도되고, 공유되었고, 논문들도 발표되었다. 그 패턴 중 하나가 MVC다.
::초창기 모델 (JSP Model 1)
- 위 그림을 보다시피 MVC패턴이라고 보이지 않을 것이다. 초창기 개발 방식은 Controller와 View가 하나의 파일에서 작업되었다. 생각해봐라 이 파일로
협업을 하게 되면 재앙이 벌어질 것이다(개발자가 디자이너가 한 파일로 작업한다면....). - 이 때는 MVC같은 모델이 존재하지 않았다. 그래서 사진에서 알 수 있듯이 로직과 출력코드가 한 페이지에서 이루어졌다. 코딩 자체는 쉬웠지만 유지보수가 상당히 어려운 코드였다(이전에는 JSP(html + java)로 개발을 했다고 한다).
- 이 Model 1 은 사용자의 인풋을 JSP가 받는다. 데이터는 JavaBean에서 관리를하고 JavaBean이 데이터를 가지고 와서 JSP로 넘겨준다. 그 데이터를 받은 JSP는 사용자에게 화면을 출력한다.
- JSP에 MVC패턴을 웹에 적용한 것이 Model 2 이다. 비즈니스와 출력 로직을 분리하여 유지보수가 좀 더 용이토록 했다. 이로인해 뷰와 로직에 대한 분업이 가능해졌다.
- 그래도 여전히 뷰와 모델은 분리되지 못한 모습이다(우리가 알고있는 뷰와 모델이 떨어진 MVC패턴과는 다른 모습이다).
- 우리가 알고 있는 MVC모델은 애플에서 발표한
Cocoa MVC의 모습이다. - 많은 사람들이 애플에서 발표한 이 MVC모델이 현재의 MVC패턴의 전신이라고 생각하는데 1979년에 트리베 린스카우 박사가 고안해낸 MVC패턴과는 다른 패턴이라고 한다(애플이 린스카우의 MVC패턴을 적용하여 발전시킨 것).
🐺 MVC
::MVC의 구조 및 역할
Model,View,Controller가 있는데 Model은 data와 애플리케이션이 무엇을 할 것인지를 정의하는 부분으로 내부 비즈니스 로직을 처리하기 위한 역할을 한다. 즉, 모델은 컨트롤러가 호출을 하면 DB와 연동하여 사용자의 입출력 데이터를 다루는 일과 같은 데이터와 관련된 비즈니스 로직을 처리한다.
Model은 두 가지 규칙이 있는데, 첫 번째는 사용자가 받아야 하는 모든 데이터를 가지고 있어야 한다. 둘째는 View나 Controller에 대해서 어떤 정보도 알지 못해야 한다.
View는 사용자에게 보여주는 화면에 해당한다(html, css)사용자와 상호작용을 하면서 Controller에게 받은 모델의 결과값을 사용자에게 화면으로 출력하는 일을 한다.
View역시 두 가지 규칙이 있는데 첫째는 컨트롤러로 부터 전달받은 Model의 정보를 따로 저장할 수 없다. 둘째는 Model이나 Controller에 대해 어떤 정보도 알지 못해야 한다.
Controller는 Model과 view를 이어주는 인터페이스 역할을 한다. 사용자로부터 View에 요청이 있으면 Controller는 Model을 호출하여 정보를 받아와 결과를 View에게 전달하는 역할을 한다.
Controller는 Model이나 View에 대해서 알고 있어야 한다. 또한 Model이나 View의 변경을 모니터링해야 한다.
::MVC의 동작
::MVC의 특징
::MVC의 장점
- MVC의 핵심은 각 구성요소들을 독립시켜 맡은 역할에만 집중시켜 개발의 효율성을 높이고 독립된만큼 유지보수와 확장성도 용이하다.
- 비즈니스 처리 로직(Model)과 인터페이스 요소(View)를 분리시킴으로써 로직 재사용이 가능하다.
- MVC패턴은 단순하고 직관적이라 하나의 파일에 코드가 모이는 걸 방지하여 가독성과 재사용성을 증가시킨다.
::MVC의 한계점
🐗 MVP
::MVP 사용배경
- 앞서 올린 MVC의 한계점인 View-Model 간의 의존성을 해결하고자 함이다. 지나치게 의존적인 Model과 View의 한계점을 해결해주기 위해 Controller를 Presenter로 대체하였으며 View와 Model의 각 요소를 보다 명확하게 분리하여 그 의존성을 해결했다. MVP패턴은 MVC패턴에서 파생된만큼 Model과 View는 MVC패턴의 구조와 역할이 동일하다. 차이점이라고 하면 Controller를 Presenter로 대체한다는 것이다. 대체한 이유는 의존성을 없애기 위함이다.
::MVP의 구조와 역할
Model은 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분이다. View는 유저에게 보여지는 User Interface부분으로 Model, View 모두 MVC패턴과 동일하단 걸 알 수 있다. Presenter는 View에서 요청한 정보로 Model에서 받은 데이터를 가공하여 View에게 전달해주는 역할을 한다. 즉, Presenter는 Model과 View의 다리역할을 한다. 이렇게만 말해서는 MVC의 Controller와의 차이점을 알기가 모호할 수 있다.
::MVP의 동작
- MVC와 다르게 사용자의 Action(=== Input)이 View를 통해 들어온다.
::MVP의 특징
::MVP의 장점과 한계점
🦄 MVVM
::MVVM 사용배경
::MVVM의 구조와 역할
::MVVM의 동작
::MVVM의 특징
::MVVM의 장점과 한계
🐴 정리
- 이렇게 MVC패턴을 시작으로 파생된 MVP와 MVVM을 알아보았다. MVC와 MVP를 보완한 MVVM패턴이 제일좋은가? 그것은 아니다. 디자인 패턴은 개발에 많은 면에서 도움을 주는 수단이지만 그에 대한 선택은 개발 상황과 구조가 필수적으로 고려되어야 한다. 예시로 역할 분리가 필요없는 상황에서 이러한 디자인 패턴의 도입은 자원 낭비를 야기할 수 있다. C++, JAVA, Python, JS 등 상황과 구조에 따라 적합한 언어가 있고, 어떠한 언어가 더 좋고 나쁨을 따질 수 없듯이, 디자인 패턴 역시 환경구조에 따라 적합한 패턴이 있다. 즉, 무조건적인 디자인 패턴의 도입이 아닌 <상황과 설계 구조 및 환경에 따라 어떤 디자인 패턴의 적용이 적합한지에 대한 판단> 우선적으로 필요하며 <각 레이어의 특성과 의존성을 고려한 적합한 디자인 패턴의 적용>이 필수적으로 고려되어야 한다.
어렵다 어려워
不怕慢, 只怕站