시작하는 중
Django Class Based View 본문
Django view 작성 방법에는 Function Based View와 Class Based View가 있다.
기존에는 FBV를 통해 views.py 파일에 def를 통한 function을 선언하고 decorator와 request.method에 대한 조건을 걸어서 HTTP method를 분기처리했다.
# views.py
@api_view(['GET', 'PUT', 'DELETE', 'POST'])
def review_detail(request, review_pk):
if request.method == "GET":
review = get_object_or_404(Review, pk=review_pk)
serializer = ReviewSerializer(review)
return Response(serializer.data)
elif request.method == "PUT":
review = get_object_or_404(Review, pk=review_pk)
serializer = ReviewSerializer(review, data=request.data)
if serializer.is_valid(raise_exception=True):
serializer.save()
return Response(serializer.data)
elif request.method == "DELETE":
review = get_object_or_404(Review, pk=review_pk)
review.delete()
data = {
"delete": f"review {review_pk} is deleted",
}
return Response(data, status=status.HTTP_204_NO_CONTENT)
그렇지만 객체 지향 언어인 python의 장점을 살려서 중복되는 부분은 줄이는 방향의 class 관련된 방법이 없을까 찾아봤는데 Class Based View라는 클래스 기반의 view 작성법을 찾았다.
위의 코드를
# views.py with CBV
class ReviewDetail(generics.RetrieveUpdateDestroyAPIView):
queryset = Review.objects.all()
serializer_class = ReviewSerializer
def delete(self, request, pk):
review = get_object_or_404(Review, pk=pk)
review.delete()
data = {
"delete": f"review {pk} is deleted",
}
return Response(data)
이렇게 줄일 수 있다.
Django 자체가 사람들이 자주 쓰는 기능들을 모아둔 framework인데 Django 안에서도 계속 반복되고 자주 쓰는 코드를 패키지화하여 저장해둔 것이다.
이를 상속받아서 사용하는 것인데 바로 generics이다.
상속이 가능하여 재사용성이 높은 class를 이용해 코드의 길이를 줄이며 실수를 줄일 수 있는 것
이것이 CBV가 나온 이유일 것이다.
그렇게 생각해보면 FBV를 왜쓸까?? 하는 생각이 든다. 어차피 CBV를 통해 작성하더라도 필요한 기능이 있다면 오버라이딩해서 사용한다. delete부분에서 삭제 후 json 형식의 파일을 return하는 것은 overriding을 통해 필요하게 바꾸면 된다.
그런데 적다보면 굳이 CBV를 써야할까? 하는 생각도 든다. 어차피 적어야하는 것은 같은데 굳이 class를 상속해서 써야할 이유가 있을까?
나의 생각은
1. 굳이 상속할 필요가 없을 때
return 해야하는 데이터나 형식이 class를 상속했을 시 원하는 값이 아니기에 overriding 해야하는 상황
2. 코드의 재사용이 일어날 일이 없을 때
위의 코드에서 urls.py에서 일어나는 수많은 분기 중에서 HTTP method가 delete인 형태에서 반환형태를 바꿔야하는 경우가 Review의 detail일 경우
이렇게 쓰는게 낫지않을까 싶다.
이미 생각했다가 지운 항목이 두개가 있는데
1. 함수의 명을 get이 아니라 다르게 하고 싶을 때
이미 overrind할 수 있다. 결국 1번이나 2번에 따라 하고 싶을 때 하는게 좋을 것 같다.
2. 두개 이상의 field, form, model, serializer를 선택할 때
아직 이런 일이 없어서 고민해봐야할 듯 싶다.
'Django > 정리' 카테고리의 다른 글
Django - 장고의 url 처리, MTV (0) | 2022.10.06 |
---|---|
Django - 장고란 (0) | 2022.10.06 |
Django - 장고 시작하기 (명령어) (0) | 2022.10.06 |
Django - 디자인 패턴 (0) | 2022.10.06 |