📚 MVC 패턴

• 애플리케이션을 세 가지 역할로 구분한 개발 방법론

Model (데이터를 다루는 셰프)

• DB와 직접적으로 통신하는 영역
• controller에서의 명령을 받고 DB에서의 데이터를 저장하거나 삭제, 업데이트, 변환등의 작업을 수행
  • 유저가 편집하길 원하는 모든 데이터를 가지고 있어야 함
  • View나 Controller에 대한 어떤 정보도 가지고 있으면 안됨 ➞ 오로지 데이터와 관련된 작업만!
  • 누군가 모델 변경을 요청하는 이벤트를 보냈을 때 이를 받을 수 있는 방법을 구현해야 함
    ➞ 모델은 재사용이 가등하도록, 다른 인터페이스에서도 변화지 말아야 함

View (셰프가 요리한 데이터를 세팅하는 직원)

• 시각적인 부분을 담당하는 역할
• 해당 부분은 프론트쪽

Controller (데이터의 흐름을 관리하는 매니저)

• model과 view사이의 상호동작을 관리하는 영역

흐름

• 사용자가 Controller를 조작하면 Controller는 Model을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달

Web과 MVC

1. 사용자가 웹사이트에 접속한다. (Uses)
2. Controller는 사용자가 요청한 웹페이지를 서비스 하기 위해서 모델을 호출한다. (Manipulates)
3. 모델은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후에 그 결과를 리턴한다.
4. Controller는 Model이 리턴한 결과를 View에 반영한다. (Updates)
5. 데이터가 반영된 VIew는 사용자에게 보여진다. (Sees)
   

장점

• MVC패턴은 서로 분리되어 각자의 역할에 집중하게 하는 개발 방법론으로 해당 패턴으로 만들어진 애플리케이션은 유지보수성, 애플리케이션의 확장성, 그리고 유연성이 증가하고, 중복코딩이라는 문제점 또한 사라지게 된다.

추가로 Service

• API에서 로직을 담당하는 영역
• Controller는 화면에서 넘어오는 매개변수들을 이용해 Service 객체를 호출하는 역할
• Service 는 불필요하게 Http 통신을 위한 HttpServlet을 상속 받을 필요도 없는 순수한 자바 객체로 구성된다(그렇기에 Service 에 request나 response와 같은 객체를 매개변수로 받아선 안된다. 그걸 사용해야하는 작업은 컨트롤러에서 해야한다.). 그렇기에 자신을 어떤 컨트롤러가 호출하든 상관없이 필요한 매개변수만 준다면 자신의 비즈니스로직을 처리하게된다.

references
https://m.blog.naver.com/jhc9639/220967034588
https://velog.io/@c_hyun403/Flask-DB-design-patterns-MVC