00pen

가끔 django와 관련된 글들을 보면 django가 mvc 패턴을 따르도록(?) 되어있다고 되어있는데 반은 맞고 반은 틀린 말 같다.

왜냐하면 동작하는 방식은 mvc 패턴이 맞는데 사용하는 단어들은 mvc패턴과 약간 다르기 때문이다. spring을 보면 mvc 패턴을 따르게 만들면 사용하는 클래스들의 이름도 model, view, controller다. 근데 django에는 controller가 없다. view도 그 view가 아닌 것 같다(!) django에서는 urls, views들이 합쳐져서 controller의 역할한다고 봐도 무방할 것 같다. 그리고 mvc pattern에서 view는 사용자가 보는 걸 지칭하는데 django에서는 template이 그 역할을 한다. 이런 것들이 django mvc라고 검색을 하면 mvt(model, view, template)라는 단어가 같이 등장하는 이유라고 볼 수 있을 것 같다.

또 django에서는 단순히 template가 view만을 대체하는 게 아니라 forms를 포함시킬 수도 있다. django rest framework가 아닌 순수한 django를 사용하게 되면 template를 만들 때 forms.py를 이용해서 form을 만듦과 동시에 validation을 수행할 수도 있다.특히 이걸 잘 다루기 위해서 jinja2라는 언어(?)를 알아두면 좋다. spring에서는 thymeleaf라는 모듈이 있듯이. 근데 백엔드 개발을 하다보면 오히려 이런 template 언어를 다뤄야할 때 어려움을 겪는 것 같다...ㅋㅋㅋ

Function Based View를 사용하고 싶으면 @api_view

Class Based View 사용하고 싶으면 APIView, Generics.~~APIView, Viewset 중 하나

APIView는 View(Rest Framework에 있는게 아닌 Django에 있는 것)를 상속받긴 하지만 거의 백지상태. 안에 만들고 싶은 Http method를 골라서 만들어주면 됨. (ex. get, post, put, delete ...)

Generics.~~APIView와 APIView 사이에 GenericAPIView가 있긴 한데 둘을 이어주는 징검다리 느낌. GenericAPIView를 써본 적은 없음. 이제 ListAPIView, ListCreateAPIView, DestroyAPIView 등등이 있는데 단어 하나가 붙을 때마다 그 Mixin같이 따라 온 거라 보면 됨. (ex. ListAPIView는 APIView에 ListModelMixin이 같이 와서 List Method를 이미 어느정도 만들어 놓음)

Generics에 있는 View들은 get, post, put, delete method를 잘 가공해서 List( or Retrieve), Create, Update, Destory로 만들어 놓음. 그래서 get, post method를 보면 그냥 가공해 놓음 List( or Retrieve), Create method를 부르기만 함.

Viewset과 APIView 사이에도 GenreicViewset이 있긴 한데 이것또한 징검다리 같은 느낌. Viewset들은 위의 Mixin들은 많이 넣어서 더 편리하게 만들어 놓음. ModelViewSet은 Mixin들을 모두 넣어 놓았고, ReadOnlyModelViewSet은 get만 가지도록 List와 Retrieve Mixin만 가져옴.

참고 문헌: http://www.cdrf.co/