MTV패턴에서 MVC패턴으로 아키텍처 변경, 기존 코드의 문제점 분석과 해결책 제시

https://github.com/InhaBas/Inhabas.com/discussions/76

새로운 아키텍처 고민 · Discussion #76 · InhaBas/Inhabas.com

시험이 끝이나고 IBAS 웹 사이트 운영에 착수하였다,,

나는 과연 잘할 수 있을 것인가,,

 

일단 디스커션에 올라온 내용들부터 완벽히 이해해보자.

 

DB와 Views

 

'view 안에서 db속성값을 기술하니, 가독성이 떨어짐'

속성 : 인스턴스로 관리하고자 하는, 더 이상 분리되지 않는 최소의 데이터 단위

정리하면, 객체는 여러 개의 인스턴스를 가지는데, 각각의 인스턴스가 가지고 있는 동일한 성격을 명명해 '속성'으로 자리매김하는 것이다. 하나의 속성은 하나의 인스턴스에만 존재하며 (이 말 잘 모르겠음), 각각의 속성에는 연관 관계가 없다. 속성은 또 다른 속성을 스스로 가질 수 없다 .

인스턴스 : 객체에서 파생된 하나의 데이터 형태를 의미한다. 객체는 모든 인스턴스를 대표하는 포괄적인 의미를 가짐

결국엔 이런 형태를 말한 것이다.

board_type_no는 DB 내의 board_type이라는 테이블의 PK이다.

select 해보니 이렇게 되어있는데, 이렇게 board_type_no라는 인스턴스 내부의 속성값을 그대로 보여주어 코딩하는 것을 문제 삼았다고 할 수 있다. 

 

'db 최적화 등의 이유로 추후 db 모델을 변경할 때, 모든 views 에서 일일히 변경해야함. 다 완벽하게 찾을 수 없음.'

이건 코드 내에서 문제가 되는 코드 포인트를 찾을 수 없다 ㅠㅠ

나중에 물어보기

 

 

'장고 ORM 쿼리를 views 에서 직접 날리는 것 안좋은 듯.'

PK로 가져온 board, 혹은 FileForm 클래스에서 POST 형태로 가져온 file_form이라는 인스턴스에서 save()를 호출한다.

save 함수는 forms.py에서 정의한 함수로, super().save()의 인스턴스를 반환받아 board에 저장한다. 

이는 insert SQL를 실행해서 DB와 통신한다. 

https://haeyong27.github.io/django/2019/11/12/django-orm-create-save/#django-orm-create-save

Django ORM create, save · 풀스택 개발 공부로그

 

 

DB와 forms

'현재는 클라이언트 사이드를 장고 템플릿 언어로 해결하고 있지만, 향후 vue로 분리될 것을 생각하면, forms 는 vaildation의 역할만 하게 됨'

클라이언트 사이드는 요청을 보내는, 그러니까 프론트 단이라고 생각하면 되는건가?

 

(서버와 클라이언트 복습)

https://www.youtube.com/watch?v=yBPyzaccbkc

강의력 미쳤다.. 

 

아무튼 이렇게 요청을 보내는 측을 장고 템플릿 언어 {{ }} , {% %} 를 사용해 HTML 파일로 만들고 있었는데, 

향후 Vue.js로 바뀔 것을 고려해 return render()이 아닌 JSON 객체를 반환하는 형태로 만들겠다는 얘기?

 

기존에 사용되고 있던 forms.py 파일은 BoardForm에 대해서 save, update함수를 정의한 클래스를 만들어놓은 곳이다. 

vue.js가 도입되면 forms.py는 원래의 기능이 필요없고 객체의 Validation의 용도로만 쓰인다...

 

--> 잘 모르겠으니까 물어보기

 

 

그래서 어떻게 해야되나?

DB 기존의 MVT모델 (model, view, template) 구조를 MVC로 변경한다. 

models.py를 entity.py로 대체한다. (entity.py는 core를 담당)

 

'ORM객체를 가져와 entity로 변환하는 repository.py (DB 와 server API core 사이의 인터페이스), ORM 상세를 신경쓰지 않도록 한다.'

즉, 테이블과 매핑될 객체를 가져와 entity로 변환하는 respository.py 생성 

이 repository.py는 DB와 server API core, 즉 entity에 정의된 model 간의 상호작용을 담당하는 것이다. 

그럼 여기서 장고 ORM 쿼리를 날리는 것이겠지?

+ ORM 상세는 QuerySet을 의미하는것이라 예상해본다..

 

그리고 interactor.py를 만들어 Controller의 역할을 수행하는 파일을 생성한다. 

여기서는 Use Case에 대한 로직을 담당. respository를 통해 변환된 entity를 다룬다. 

(변환된, 이라는 말은 어떤 의미,,? validation을 거쳤다는 건가? entity와 ORM 객체의 차이점을 사실 잘 모르겠음,,

ORM은 테이블과 Entity를 매핑하는 '행위'를 의미하는 것이 아닌가? "ORM 객체"의 정의 관련해서 공부해오기)

+ Use Case : 요구사항이라고 보면 됨

 

views.py에서 위 interactor.py에서 정의된 객체를 Use Case에 맞추어 적절히 처리 . (response, status) 를 리턴한다. 

+ Serializer : 직렬화, 파이썬 데이터를 JSON 타입의 데이터로 변환하는 것을 의미

'주의할 점은, 함수나 클래스 내부에서 종속되게 사용하는 것이 아니라, 외부에서 주입하는 형태로 사용해야함.'

이 부분 이해 안됨,, 질문하기 ㅜㅜㅜ 

 

++views.py의 외부 의존성

validation, auth check 등등 -> views Wrapper에서 처리하기

(이건 우선순위 조금 낮게 두고,,)

 

단점

'계층이 많아지는 만큼, 보일러 플레이트도 증가'

보일러 플레이트 : 변경 없이 계속 쓸 수 있는 저작품, 반복적으로 비슷한 형태를 띄는 코드가 많아질 때 반복적인 코드를 자동화하여 필요한 코딩을 할 수 있게 한다. 

-> 자동화된 라이브러리? 들을 자주 쓰게 되니까 단점이라고 하는건가.,?