• 사용자의 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴입니다.

• Model

  데이터와 비즈니스 로직 관리

• Controll

  명령을 모델과 뷰 부분으로 라우팅한다.

  • Accepts input and converts it to commands for the model or view - wikipedia

• View

  레이아웃과 화면처리

코드에서 MVC를 지키기 위한 규칙

1. Model은 View와 Controller에 의존하지 않는다.
2. View는 Model에만 의존하고 Controller에는 의존하지 않는다.
3. View는 사용자마다 다르게 보여져야 하는 데이터만 받아야 한다.
4. 컨트롤러는 모델과 뷰 둘다 의존 가능.
5. View는 모델의 데이터를 받을 때 반드시 컨트롤러를 통해 받아야 한다
   1. 즉, parameter로 패싱 받아야 한다는 의미인듯?

[10분 테코톡] 🧀 제리의 MVC 패턴

• 코드상으로는 똑같은데 목적성에 따라 이름이 달라지기도 함
  • VO, DTO, Entity, ContextObject
  • HTTP protocol로 parameter나 path variable을 받는데, 이런 특정 환경에 있는 데이터를 받아서 Context Object라고 부른다
    • JavaEE에서 사용하는 패턴
  • Request 받아서 가공하는 것을 Context Object
  • 컨트롤러에서 서비스로 이동할 때 이것을 DTO로 변환시켜서 이동
  • 변환된 DTO를 DAO로 옮긴 뒤에 DAO에서 DBMS와 통신할 때는 Entity Object로 통신
• 우리는 DTO 하나로 썼었는데, ContextObject, DTO, Entity등등 뭔가 변환을 막 다 해줘야 하는가
  • 해줘야 한다.
  • 패턴을 적용하다보면 생기는 단점중 하나가 클래스 수가 많아짐
  • 속도에 문제가 되지 않느냐
  • 클래스 수가 많아도 영향을 미치지 않음
  • 속도에 영향을 미치는 것은 인스턴스 수
  • 적당한 데이터와 기능은 자신의 역할과 기능만 해야한다(Responsibility)
    • 그래서 클래스 만들어야 함
• 뭐 현재 Context Object까지 나누진 않으니, DTO와 Entity까진 나눠서 설계해야함