이전에 Django를 사용했을때는 MTV patterns을 사용해 Model Template View 의 개념을 익혔고, 여기서 backend가 다루는 영역은 Model과 View 였다. 이번에 우리팀이 기업협업에서 사용할 architecture patterns는 MVC patterns이다.
MCV patterns 이 무엇인지 알아보자!!
참고자료
이분의 벨로그!
Clint Jang
큰돌의 터전
I. MVC
MVC ?
M : Model - 데이터베이스와 직접적으로 통신하는 영역
V : View - backend endpoint경로를 처리해 주는 영역. flask에서는 Flask 클래스가 route라는 method를 갖고 있고 이를 통해 client에게서 온 request를 처리한다.
=> 이부분은 별도로 FE folder로 관리한다. 때문에 BE folder에서 볼 일이 없다.
C : Controller - Model과 View 사이의 상호동작을 관리하는 영역
=> 우리프로젝트에서는 이를 View 라고 명명하였다. 그래서 MVVC patterns이 되었다!
<추가>
S : Service - api에서 로직을 담당하는 영역. 만약 데이터베이스에 10글지 이상의 내용을 저장하지 않겠다고 한다면 이를 걸러주는 로직이 service에 존재해야 한다.
우리의 pattern에서는 Service가 곧 Controller이다. 따라서 pj의 folder는modelserviceview가 존재한다.
MVC !! : 즉 MVC란 Model View Controller의 줄임말로 하나의 application을 3가지 역할로 구분한 개발 방법론이다.
1. Model
application이 무엇을 할것인지에 대해 정의하는 영역
이부분에서 CRUD가 이뤄진다.
Model에는 다음과 같은 규칙이 있다.
- user가 편집하길 원하는 모든 data를 갖고 있어야 한다.
- view나 controller에 대해 어떤 정보도 갖고 있으면 안된다.
- 데이터에 변동이 일어났을때 model 에서 화면 UI를 직접 조작할수있는 일이 없도록 한다.
2. Controller
model이 어떻게 처리할지에 대해 알려주는 영역
Controller에는 다음과 같은 규칙이 있다.
- Model 이나 View에 대해서 알아야 한다.
- 이 때문에 Controller는 Model과 View의 중개역활을 수행한다.
- Model과 View의 변경사항을 인지해야 한다.
- 이 때문에 application의 메인 로직은 controller가 담당하게 된다.
Service 란?
그렇다면 우리가 사용할 구조의 Service란 무엇일까?
Service ?
MVC 패턴의 핵심은 View는 자신이 요청할 Controller만 알고있으면 되고, Controller는 화면에서 넘어오는 매개변수들을 이용해 Service 객체를 호출하는 역할을 한다.
Service 는 불필요하게 Http 통신을 위한 HttpServlet을 상속 받을 필요도 없는 순수한 자바 객체로 구성된다(그렇기에 Service 에 request나 response와 같은 객체를 매개변수로 받아선 안된다. 그걸 사용해야하는 작업은 컨트롤러에서 해야한다.). 그렇기에 자신을 어떤 컨트롤러가 호출하든 상관없이 필요한 매개변수만 준다면 자신의 비즈니스로직을 처리하게된다.즉 모듈화를 통해 어디서든 재사용이 가능한 클래스파일이라는 뜻이다.
출처
[우리집앞마당]
하지만 Controller대신 Service로 완전히 대체하여 사용하는 것도 같다. 명확히 구분되던 의미가 퇴색되어진건가? 어쨋든 Service가 위의 MVC 그림에서 Controller의 역활을 수행한다.
3. View
화면에 무엇인가를 보여주기 위한 역할을 수행하는 영역 => UI 부분
View에는 다음과 같은 규칙이 있다.
- Model이 갖고있는 정보를 따로 저장하면 안된다.
- 임무수행을 위해 model로부터 전달된 정보를 또다른 임시 view에 저장하면 안된다. 변경이 요구되면 변경을 수행하고 변경 수행에 필요한 정보는 저장하지 않는다.
- Model이나 Controller와 같이 다른 구성요소들을 몰라야 한다.
MVC patterns 와 user간의 관계를 그림으로 정리하면 다음과 같다.
4. 의의
위에서 말했듯 MVC는 Django에서 사용한 MTV와 거의 같다고 보여진다.
| MVC | Django의 MTV | 담당 |
|---|---|---|
| M | M | DB에 직접 접근 |
| V | T | 화면(보여지는 영역) |
| C | V | 로직 |
---------------------------------------
II. PJ 구조
1. tree로 확인
flask 서버: db_connect.py
Model: model/user_dao.py
View: view/user_view.py
Service: service/user_service.py
이 외에도 app.py와 config.py, run.py가 통신의 한 cycle에 필수적이다.
❯ tree
.
├── __pycache__
│ ├── app.cpython-39.pyc
│ ├── config.cpython-39.pyc
│ ├── db_connector.cpython-39.pyc
│ ├── run.cpython-39.pyc
├── app.py
├── config.py
├── db_connector.py
├── requirements.txt
├── run.py
├── model
│ ├── __init__.py
│ ├── __pycache__
│ │ ├── __init__.cpython-39.pyc
│ │ └── user_dao.cpython-39.pyc
│ └── user_dao.py
├── service
│ ├── __init__.py
│ ├── __pycache__
│ │ ├── __init__.cpython-39.pyc
│ │ └── user_service.cpython-39.pyc
│ └── user_service.py
└── view
├── __init__.py
├── __pycache__
│ ├── __init__.cpython-39.pyc
│ └── user_view.cpython-39.pyc
└── user_view.py
2. Flask 통신 flow 확인하기
내가 짠 로직에서 통신이 요청됐을때 어떤 file의 경로를 지나가는지 확인하기 위해 열심히 print를 찍어보았다.
db_connector.py와 app.py
view.py와 service.py
model.py (좌 : 중복된 유저가 있는지 찾는 함수 / 우 : 새로 유저를 등록시키는 함수)
경로 확인
- 먼저 서버가 새로 가동되거나 가동된 상태에서 pj의 상태가 새로 저장되면
app.py가 실행된다. => app 1번입니다 - 통신을 통해 가장 먼저
view.py가 실행된다 => view 1번입니다. - db_connet()로
db_connect.py가 실행된다 => db와 연결을 시작합니다 - view에서 마저 로직이 실행된 후 service가 불러와 지는 때에
service.py가 실행된다. => service 1번입니다 - service.py의 로직 순서에 따라
models.py가 실행된다. => find_user / create_user / create_user_log - service.py의 로직이 마무리 된다 => service 2번입니다
- view.py의 로직이 마무리 되며 raise에 따라 결과값이 처리된다 => view 4번 입니다
- 설정한 response처리방식에 따라 처리된다(설명 생략) =>response / app 2번입니다
즉, 요청이 들어오면 view => service => models => service => view 순서로 진행된다는 것을 확인할 수 있었다!
