레이어드 아키텍처 형식으로 개발하기 위해 인터넷도 찾아보고 자료를 찾아가면서 VIEW, SERVICE, MODLE 의 구조로 혼자 만들어 봤지만 멘토님과 완전히 잘못 됬다는 점을 알게 되었다.
잘못된 점
- 처음 생각에 FLASK_APP을 View에 있는 파일로 실행을 시킬려고 했다.
-> View역시 단순히 api를 만드는 역할만 하기 때문에 서버를 돌리기 위한 run.py(local_api.py)를 다시 만들어 주었다. - 데이터 베이스를 연동시키는 역할도 model에 넣어놓았다.
-> 데이터베이스의 테이블을 만들어 주는 역할은 api가 아니기 때문에 migration파일을 모아두는 장소를 api 외부에 만들어 주었다. - 'init.py'를 간과했다.
그래서 처음부터 끝까지 세팅을 다 다시 해주었다.
초기세팅
- Layered Arcitecture 형식에 맞게 VIEW, SERVICE, MODEL 구현 하기
- mysql 연동하기
Layered Arcitecture의 형식에 맞게 재구성하기
완성본
MODEL(persistence layor)
데이터베이스와의 연결의 역할만 하는 model 에는 user테이블에 데이터를 저장하기 위한 user_dao, 챗봇을 사용하는 사용자의 상태를 관리해주기 위해 message데이터를 저장하고 가져오기 위한 message_dao, CGV의 이름과 코드번호를 가져오기 위한 theater_dao를 만들어 주었다.
대표적으로 theater_dao를 보면
이런식으로 db에서 데이터를 가져오는 로직뿐이 없다.
SERVICE(business layor)
SERVICE는 실제로 시스템이 구현해야 하는 로직들을 구성하는 장소이다. facebook의 message를 전체적으로 관리하는 facebook_service.py, BOXOFFICE 10위까지 가져오는 service를 제공하는 movie_service.py, 주변의 CGV를 찾아서 검색해주는 place_service.py, user에 sender_id를 view로 보내주는user_service.py, 해당 영화관의 영화시간표를 찾아주는 theater_service.py가 있다.
대표적으로 theater_service를 보면
get_movies는 CGV홈페이지를 크롤링을 해서 가져온 html 파일들을 parser해주는 로직으로 영화시간과 이름이 있는 전체 부분을 movies리턴을 해준다.
그 movies를 가지고 get_timetable은 그 영화관에서 상영하고 영화의 제목, 영화관의 이름과, timetable을 가져왔다.
이렇게 db에 접근하지도 않고 api를 만들어 주지도 않고 단순히 우리가 제공하고 싶은 service(business)만 구현했다.
VIEW(presentation layor)
endpoint 들을 정의하는 코드를 모아 놓은 부분으로 우리가 원하는 서비스를 구현한다거나, 데이터베이스에 접근을 하는 등의 역활은 하지 않는다.
보시다 시피 view는 단순히 api를 구현하는 역할만을 하기때문에 'init.py'만이 존재 할 뿐 다른 파일은 존재하지 않는다.
view 부분의 로직이다. 오직 endpoint를 만들기 위한 로직만이 있을뿐 다른 내용은 일체 존재하지 않는다.
이런식으로 VIEW, MODEL, SERVICE 를 확실하게 각 역할을 구분을 지어 줌으로서 오류가 일어난 부분을 정확히 알 수 있게 되고, 나중에 코드를 확장 할때 더욱 용이하고 쉽게 할 수 있다.
그 외
api폴더의 init.py
model, view, service폴더를 담아놓은 api 폴더 이다. 여기서 init.py를 볼 수 있는데 이 파일은 service, model에 있는 파일을 import를 더욱 용이하게 하기 위해 모아놓은 파일이다. 지금 init.py라고 되어 있지만 파일들을 주입해 놓아서 그런지 injecter.py로도 명해서 사용하기도 한다.
이런식으로 모든 model에 있는 dao 파일들과 service 파일들을 모아 놓고 유기적이고 더욱 효율적으로 import를 가능하게 한다.
config.py
django에서의 mysettings.py와 settings.py가 모여있는 장소 라고 생각 하면 된다. 외부api들을 사용하는데 있어 필요한 apikey들이나 token들을 저장해 놓고 있는 장소이다. 그리고 데이터베이스를 연결하는데있어 필요한 HOST, PORT, NAME 등을 여기에 만들어 놓고 연결을 위한 DB_connection을 구현해 준다.
local_api.py
flask 서버를 돌릴때 사용하는 파일 이다. Run.py라고도 한다.
코드는 이런식으로 Run.py를 통해서 flask를 돌려서 가능하다.
db
처음에는 외부 api만을 사용해서 데이터베이스를 사용할 필요성을 느끼지 못해서 초기세팅을 하지 않았지만, user의 상태를 관리하는 부분이나, cgv코드를 가져오는데 있어서 필요하다는 점을 도중에 알아서 급하게 세팅을 해주었다.
django에서는 데이터베이스를 만들어 주는데 있어서, migration migrate를 해서 테이블을 만들어 줄 수 있었지만, flask는 테이블을 직접적으로 만들어 줘야 했다.
01_create_cgv_table.py 이런식으로 migration파일을 직접 만들어서 관리 해주었다.
yoyo migration 을 통해서 테이블을 만들어 주었다.
그리고 Row query를 사용해서 만들어 주었다.
테이블 생성 완료
초기세팅 완료!!
