MVC란
MVC 패턴은 디자인 패턴 중에 하나입니다.
디자인 패턴

출처: Think Different
- 과거의 소프트웨어 개발 과정에서 발전된 설계의 노하우를 축적하여 그 방법을 재사용하기 좋은 형태로 특정 규약을 만들어서 정리한 것입니다.
- 공통적인 문제들에 대한 표준적 해법을 제시합니다.
- 특정 상황에서 구조적 문제를 해결하는 방식입니다.
- 구현자들간의 커뮤니케이션의 효율성을 높입니다.
MVC란

출처: 위키백과
- MVC는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는 데에 널리 사용되는 소프트웨어 디자인 패턴입니다.
- 어플리케이션, 프로젝트를 구성할 때 그 구성요소를 세 가지의 역할로 구분한 패턴입니다.
- 이 패턴을 성공적으로 사용한다면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 어플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 어플리케이션을 만들 수 있습니다.
Model(M)
- Model이란 어플리케이션이 포함해야 할 데이터가 무엇인지를 정의합니다.
- 데이터의 상태가 변경됐을 때, view 또는 controller에게 이를 알리기도 합니다.
- 데이터베이스와 연동을 담당하는 부분이라고 볼 수 있습니다.
- DAO: Data Access Object
- DB를 사용해서 데이터를 조회 혹은 조작하는 기능을 전담하도록 만든 객체입니다.
- DB에 접근하고 DB를 사용해 데이터를 조회/조작하는 기능을 담당합니다.
- 즉, DB에 접근하여 데이터의 CRUD를 할 수 있는 기능을 수행합니다.
- 장점
- DB에서 효율적으로 쿼리를 받아들일 수 있습니다.
- 유지보수를 편하게 할 수 있도록 합니다.
- VO: Value Object
- 각 계층 간의 데이터 교환을 위한 자바 객체입니다.
- 계층 간의 데이터 교환을 위한 Java Beans입니다.
- DB의 한 테이블에 존재하는 컬럼들을 멤버 변수로 작성하고, 테이블의 컬럼 값을 Java에서 객체로 다루기 위해 사용합니다.
- 데이터들을 캡슐화 하여 객체로 만든 것입니다.
- 객체의 속성(properties)과 getter, setter를 갖고 있습니다.
- 규칙
- 사용자가 편집하길 원하는 모든 데이터들을 갖고 있어야 합니다.
- View나 Controller에 대한 정보를 알지 않아야 합니다.
- 변경이 일어날 때에는 변경 통지에 대한 처리 방법을 구현해야 합니다.
View(V)
- 사용자와 어플리케이션 사이의 상호작용에 대한 세부 내역을 캡슐화하는 역할을 수행합니다.
- 사용자가 보는 화면에 입출력 및 결과를 보여주기 위한 역할을 합니다.
- 내부에 클라이언트로 전송될 컨텐츠들을 생성하는 HTML 템플릿입니다.
- 규칙
- Model이 갖고 있는 정보를 따로 저장해서는 안됩니다.
- Model과 Controller와 같은 다른 구성요소들을 알지 않아야 합니다.
- 변경이 일어날 때에는 변경 통지에 대한 처리 방법을 구현해야 합니다.
Controller(C)
- Model과 View를 연결시켜주는 역할을 합니다.
- Model이 어떻게 처리할지를 알려주는 역할을 합니다.
- 도메인 객체들의 조합을 통해 프로그램의 작동 순서나 방식을 제어합니다.
- 사용자가 데이터를 클릭하고 수정하는 것에 대한 이벤트를 처리하는 부분입니다.
- 규칙
- Model 및 View에 대해서 알고 있어야 합니다.
- Model 및 View의 변경을 모니터링 해야 합니다.
MVC 장점
- 유연하고 확장성이 좋습니다.
- 협업에 유리합니다.
- 유지보수 비용을 절감할 수 있습니다.
- 각자 맡은 부분의 개발에만 집중할 수 있어 개발의 효율성을 높입니다.
MVC 단점
- 클래스들이 많이 필요하여 복잡할 수 있습니다.
- 설계 시간이 오래 걸립니다.
- Model과 View의 완벽한 분리가 어렵습니다.
- 다수의 Model과 해당하는 다수의 View는 하나의 Controller를 통해서 소통을 이루기 때문에 Model과 View 사이의 의존성은 완벽히 분리될 수는 없습니다.
출처:
https://m.blog.naver.com/jhc9639/220967034588
https://ko.wikipedia.org/wiki/%EB%AA%A8%EB%8D%B8-%EB%B7%B0-%EC%BB%A8%ED%8A%B8%EB%A1%A4%EB%9F%AC