[아키텍처 패턴] MVC 패턴이란?
MVC는 Model-View-Controller 의 약자.
개발 할 때, 3가지 형태로 역할을 나누어 개발하는 방법론.
비지니스 처리 로직과 사용자 인터페이스 요소들을 분리시켜 서로 영향없이 개발 하기 수월하다는 장점이 있다.
Model은 어플리케이션이 “무엇”을 할 것인지를 정의한다. 내부 비지니스 로직을 처리하기 위한 역할을 한다.
- 처리되는 알고리즘, DB 와 상호작용(CRUD Create Read Update Delete), 데이터 등등..
Controller는 모델이 “어떻게” 처리될 지를 알려주고, 모바일에서는 화면의 로직처리 부분이다. 화면에서 사용자의 요청을 받아서 처리되는 부분을 구현되게 되며, 요청 내용을 분석해서 모델과 뷰에 업데이트 요청한다.
- 사용자로 부터의 입력 을 받고 모델 또는 뷰의 중개인 역할
View는 화면에 “무엇” 인가를 “보여주기 위한 역할”을 한다. 컨트롤러 하위에 종속되어, 모델이나 컨트롤러가 보여주려고 하는 모든 것들을 보여준다.
- 최종 사용자에게 “무엇”을 UI(화면)으로 보여줌
그리고 컨트롤러는 모델과 뷰가 각각 무엇을 해야 할 지를 알고 통제한다. 비지니스 로직을 처리하는 모델과 UI에 의존적인 뷰가 서로 직접 이야기 할 수 없게 한다.
MVC의 한계
MVC에서 뷰는 컨트롤러에 연결되어 화면을 구성하는 단위요소이므로 다수의 뷰들을 가질 수 있다. 그리고 모델은 컨트롤러를 통해서 뷰와 연결되지만, 이렇게 컨트롤러를 통해서 하나의 뷰에 연결될 수 있는 모델도 여러개가 될 수 있다.
뷰와 모델이 서로 의존성을 띄게 된다.
즉, 화면에 복잡한 화면과 데이터의 구성 필요한 구성이라면, 컨트롤러에 다수의 모델과 뷰가 복잡하게 연결되어 있는 상황이 생길 수 있다.
MVC가 너무 복잡하고 비대해져서, 새 기능을 추가할때마다 크고 작은 문제점을 가지고 소드 분석이나 테스트도 어렵. 이런 형태의 MVC를
Massive ViewController (대규모 MVC 어플리케이션)
라고 부른다. MVC의 한계를 표현한 용어이다.
대부분의 사람들은 MVC를 구성할 때,뷰와 오델을 중재하는 컨트롤러를 작성하면 컨트롤러의 비중이 크지 않을 것으로 생각하지만, 복잡한 화면을 구현하게 되면 대규모 MVC 어플리케이션 형태로 구현한다.
컨트롤러는 뷰와 라이프 사이클과 강하게 연결되어있어서 분리할 수도 없고, 코드 분석/수정과 테스트가 모두 힘들어지는게 단점이다. 그리고 복잡하게 엮어있는 모델과 뷰는 여러 사이드 이펙트를 불러와서 프로그램 운영을 힘들게한다.
그래서 위의 문제점을 보완한 여러 다양한!! 패턴을 파생시켰다.
- 간단하게 이미지로 표현해 보면..
왼쪽은 간결하게 핵심을 표현, 오른쪽은 왼쪽과 같은 의미이지만 해석에 따라 조금 다르게 그려질 수도 있다.
Entity :
Entity는 실제 DB 테이블과 매핑되는 클래스다. Entity를 기준으로 테이블이 생성되고 스키마가 변경된다.
VO :
데이터를 담는 객체로 ReadOnly의 성향이 강해 setter는 사용하지 않는다.
DTO (Data Transfer Object) :
데이터 전송에 쓰이는 객체이며 다른 비즈니스 로직에 전송할 때 사용한다. getter와 setter를 쓸 수 있으며 불변 객체로 쓰고싶을 경우 setter를 안쓰고 생성자를 이용해서 초기화하는 방법을 고려해볼 수 있다.
getter, setter 이외의 로직이 들어갈 수도 있다 vs 그렇지 않다 이렇게 갈리는 것 같은데 그 점에 대해서는 개발자 마음인 것 같다...!
팀장님이 말씀해주신 소프트웨어공학의 유스케이스 다이어그램/클래스 다이어그램/시퀀스 다이어그램?? 요고 계속 알아보기
********** 새 프젝 시작해서
오늘 하루종일 명세서만 작성했는데 ,, 어휴,, 넘 ㅜ딥하게 들어가서 튜터님들만 오지게 괴롭혔는데 결국 마지막 튜터님이 너무 딥하다고,, 조심스럽게 말씀 주셔서 다 걷어내니까 30분만에 명세서 다 짠거 실화?ㅠㅠㅠ
내일 다같이 빡코딩 하기로 하고 열심히 명세서 썼다.