Model | View | Controller
Model-View-Controller 의 약자로 애플리케이션을 세 가지 역할로 구분한 개발 방법론
유저가 Controller 를 조작하면 Controller 는 Model 을 통해 데이터를 가져오고 그 데이터를 바탕으로 View 를 통해 시각적인 부분을 제어하여 사용자에게 전달하게 됩니다.
이러한 패턴은 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나
그 이면에서 실행되는 비즈니스 로지을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있게 됩니다.
예를 들면
사용자가 웹 사이트에 접속을 하고, Controller 는 사용자가 요청한 웹 페이지를 서비스하기 위해서 Model을 호출 합니다. Model 은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후 그 결과를 return 합니다. Controller 는 Model 이 return 한 결과를 view 에 반영합니다.
데이터가 반영된 view 는 사용자에게 보여지게 됩니다.
package Example.Mvc
@Getter
@NoArgsContructor
public class User {
private Int id;
private String name;
public user(Int id, String bread){
this.id = id;
this.name = name;
}
}package Example.Mvc
@Controller
public class UserController {
private final UserService userService // DB 조회 서비스 단
@GetMapping("/search/user")
public String searchUser(@PathVariable String name Model model){
boolean result = breadService.findByName(name);
model.addAttribute("result", result);
}
}View
<c:choose>
<c:when test="${result}">
<p> 해당 빵은 존재 합니다.</p>
</c:when>MVC 패턴에는 모델 방식이 2가지가 존재합니다.
Model1: JSP에서 로직과 출력을 전부 담당하고 처리
-장점
빠르고 쉽게 개발이 가능하다.
-단점
JSP 파일이 너무 비대해지며 Controller 와 View 가 같이 있으므로 향후 유지보수에 어려움
Model2. JSP에서 출력만을 담당하고 처리
-장점
디자이너와 개발자의 분업이 가능하며 유지보수 및 확장이 쉬움
-단점
설계가 어려우며 개발 난이도가 높음
Model1
클라이언트 측에 View 를 요청하고 서버측에 Model 쪽에 데이터를 보내고 DB에
전송하게 되면 DB 에서는 다시 Model 에 보내고 Controller를 사용하여 웹 브라우저에서 사용자가 요청한 작업을 처리하고 그 결과를 출력 합니다.
Model2
웹 브라우저 사용자의 요청을 서블릿이 받고, 서블릿은 해당 요청으로 View를 보여줄 것인지 Model 로 보낼 것인지 판단하여 전송 합니다. 또한 모델2 방식의 경우 HTML 소스와 Java 소스를 분리해놓았기 때문에, 모델1 방식에 비해 확장시키기도 쉽고 유지보수 또한 쉽습니다.
모델(Model)
데이터를 가진 객체를 지칭
데이터는 내부의 상태에 대한 정보를 가질 수도있고, 모델을 표현하는 이름 속성으로 가질 수 있다.
모델의 상태에 변화가 있을 떄 컨트롤러와 뷰에 이를 전달, 전달받은 데이터를 통해 뷰는 최신의 결과를 보여줄 수도있고, 컨트롤러는 모델의 변화에 따른 적용이 가능한 명령을 추가, 제거, 수정 할 수 있음
모델의 규칙
사용자가 편집하길 원하는 모든 데이터를 갖고 있다.
뷰나 컨트롤러에 대해서 어떠한 정보도 알 수 없다.
변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야한다.
뷰(View)
View는 클라이언트 측 기술은 HTML/CSS/Javascript 들을 모아둔 컨테이너
사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 얻어옴
뷰의 규칙
모델이 가지고 있는 정보를 따로 저장해서는 안됨
모델이나 컨트롤러와 같이 다른 구성 요소를 몰라야한다.
변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 한다.
컨트롤러(Controller)
사용자가 접근한 URL에 따라 사용자의 요청사항을 파악하고, 그 요청에 맞는
데이터를 Model에게 요청하고, 데이터를 View에 반영해서 사용자에게 보여줍니다.
모델에 명령을 보냄으로서 뷰의 상태를 변경할 수 있습니다.
컨트롤러가 관련된 모델에 명령을 보냄으로서 뷰의 표시 방식을 변경할 수 있습니다.
뷰의 표시방식이라 함은 문서를 스크롤 하거나 하는 부분등을 의미 합니다.
컨트롤러의 규칙
모델이나 뷰에 대해서 알고 있어야 한다.
모델이나 뷰의 변경을 모니터링 한다.
MVC 패턴의 한계
MVC패턴에서 View는 Controller에 연결되어 화면을 구성하는 단위 요소 이므로 다수의 View를
가질 수 있습니다. 그리고 Model은 Controller를 통해서 View와 연결되지만, Controller에 의해서 하나의 View에 연결될 수 있는 Model도 여러개가 될 수 있어 View와 Model이 서로 의존성을 띄게 됩니다. 즉 Controller에 다수의 Model과 View 가 복잡하게 연결되어 있는 상황이 발생할 수 있습니다.
정리
Model: Background 에서 동작하는 Buisness Logic의 데이터를 처리
View : 정보를 화면으로 보여주는 역할
Controller : 사용자의 입력 처리와 흐름 제어 담당. 화면에 Model과 View 를 연결시켜주는 역할
