[Django] CRUD Operation(1)

CRUD Operation

- 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말

- 웹 어플리케이션에서도 모델은 기본적으로  CRUD의 4가지 방식으로 동작한다

 

 

목표

- CRUD Operation에서 Read

- 데이터베이스에 저장된 데이터를 읽어오기

 

저번 블로그 포스트에서 Django 관리자 기능을 활용해 데이터베이스에 데이터를 생성하고,

데이터베이스에 저장된 레코드를 쿼리셋으로 모두 받아오는 방법을 알아보았다.

 

이번에는 데이터베이스에 저장된 각 레코드 하나를 표현할 수 있는 화면과 로직을 구성해보자

 

 

html 파일 생성

- 지난 포스트에서 생성했던 Blog에 대한 레코드 하나를 표현할 html하나를 생성

- app 디렉토리 내의 templates 디렉토리 안에 detail.html 생성

 

 

views.py

from django.shortcuts import render, get_object_or_404

...

def detail(request, post_id):
    post = get_object_or_404(Post, pk=post_id)
    return render(request, 'detail.html', {'post' : post})

 

url의 요청에 따라 해당 페이지로 이동할 수 있는 함수를 하나 추가한다.

 

1) 먼저 get_object_or_404 메소드를 import 해준다.

 

2) detail 메소드를 정의하는데 인자 값으로 request 말고 post_id를 하나 더 받게 된다. post_id는 해당 레코드를 식별하기 위한 id 값이다

 

3) get_object_or_404 메소드에 매개변수로 클래스명(테이블명)의 레코드를 식별하기위한 id(기본키)를 전달한다. get_object_or_404 메소드를 통해 해당 pk값과 일치하는 레코드가 존재하면 post에 레코드에 해당하는 쿼리셋을 전달하고, 그렇지 않으면 404 page not found에러를 출력하도록 한다.

 

4) 전달 받은 post 쿼리셋을 딕셔너리 형태로 template(detail.html)에 전달한다.

 

 

urls.py

 

path('detail/<int:post_id>/', blog.views.detail, name='detail')

 

<int:post_id>를 통해 views.py의 detail 메소드에 파라미터로 post_id를 전달해준다.

 

 

index.html

 

{% for post in posts %}
    <h1>{{post.title}}</h1>
    <p>{{post.pub_date }}</p>
    <a href="{% url 'detail' post.id %}">자세히 보기</a>
    <br>
{% endfor %}

 

index 페이지에는 전체 post에 대한 제목과 작성 시간, 각 post글에 대한 detail 페이지로 이동할 수 있는 a태그를 표시

 

 

 

detail.html

 

<h1>{{ post.title }}</h1>
<p>{{ post.pub_date }}</p>
<p>{{ post.content }}</p>

 

 

index 페이지에서 해당 글에 a 태그를 누르게 되면 해당 글의 detail.html로 넘어가게된다.

url을 보면 'detail/1/'와 같이 명시되어 있고, 이는 urls.py에서 'detail/<int:post_id>/'에 대응하는 값이다.

 

 

 

post_id로 존재하지 않는 값을 전달하게 되면 404 page not found 에러가 뜨는 것을 확인할 수 있다.

 

이는 views.py에서 get_object_or_404에서 파라미터로 전달한 5에 해당하는 post가 존재하지 않으며 쿼리셋을 반환하는 대신 404 page not found를 반환한 결과이다.

 

 

정적 웹과 동적 웹

초기의 Web은 위와 같은 정적 웹의 형태였다.

web server에서 해당 글에 대한 모든 html 파일을 가지고 있었다.

이전까지 진행했던 내용을 예를 들자면, templates 디렉터리 내에 post1.html, post2.html, post3.html...

각 post에 대한 html 파일들이 별도로 존재하고 있었다. 만약 10만개의 post가 저장되어있다고 생각하면 끔찍하다.

 

웹 사용자가 늘고, 처리해야할 데이터가 방대하게 증가함에 따라 위와 같은 구조는 무리가 있다.

 

동적 웹이 나옴에 따라 웹 서버는 html 파일에 대한 껍데기(?)만 가지고 있다.

즉, 안에 들어가야할, 사용자에 요청에 따라 시시각각 변하는 데이터는 비워둔 상태로 두고, WAS(Web Application Server)에서 동적인 컨텐츠(진행했던 프로젝트로 예를 들자면 클라이언트가 요청한 해당 post)에 대한 요청을 처리하고 Web Server에 전달하면 Web Server는 가지고 있던 html 파일에 WAS로부터 전달받은 동적인 컨텐츠를 담아 클라이언트에 응답한다.

 

이렇게 분리된 구조를 사용함으로써 지금은 각 html을 만들지 않아도 되구나! 하는 장점을 가지고 있다는 것만을 알 수 있지만,

실제로는 서버 부하를 방지하고 Web Server에 여러 대의 WAS 연결 등의 더 많은 이점들을 가지고 있다.