Django

파이썬에서 사용하는 웹프레임워크 중 하나로
flask와 같이 가장 많이 사용하는 프레임워크중 하나 이지 않을까 싶다

flask는 하나하나 만드는 느낌이라면
Django의 경우 만들어져 있는게 많아 가져다 쓰는 느낌이 있다

Django의 시작

에이드리안 홀로바티(Adrian Holovaty), 사이먼 윌리슨(Simon Willison)

당시 로렌스 저널 월드의 웹사이트는 PHP로 만들어 졌는데
로렌스 저널 월드의 인턴 프로그래머 였던 두명은 거대한 웹페이지를 만드는데 있어
PHP는 적합하지 않다고 생각했고, 이를 계기로 django를 만들기 시작했다

당시 django는 저널월드의 웹사이트만들 목적으로 만들었지만,
홀로바티와 윌리슨이 로렌스의 소유자인 더 월드 컴퍼니(The World Company)를 설득하여
오픈 소스로 공개 되었다

MTV ( MVC )

Model
View
Template

PHP, ASP, JSP의 시대에는 모델, 데이터베이스 쿼리를 날리는 부분, 디자인 등등
다양한 코드들이 한곳에 모두 모여있엇다

여러명이 작업을 할때 불편한 점이 많았고,

프로젝트가 커짐에 따라 관리가 어려워서
디자인 패턴 중에 MVC패턴을 적용하기 시작했습니다

이렇게 코드들이 분리 되기 시작했고, 지금은 MVC패턴을 따라 분리하여 관리를 하게됬습니다

Django 에서의 MTV

Django에서는 MTV라고 불리는데
Controller의 역할을 Template가 한다고 보시면 됩니다

1. client가 특정 url로 접속을 함

2. URL Dispatcher에서 URL을 분석

3. 분석한 URL에 맞는 View파일로 보내줌

4. View에서 DB에서 어떤 데이터를 가공해서 가지고 올지 Model에 전달

5. Model은 DB에서 알맞는 Data를 가지고 와서 View에게 전달

6. View -> Template로 전달

7. Template에서 WebBrower로 전달하여, client가 그 화면을 보게됨

이러한 흐름으로 장고가 진행되는데,
쿼리문을 작성하지 않고 View에서 적은 코드로 데이터베이스에서 데이터를 가지고 온다

위의 과정을 좀더 장고에게 적용해 조금 더 쪼개 보면

Django의 workflow

models.py

테이블과 컬럼을 정해준 뒤 migrate를 통해 DataBase에 전달해줌

어떤 table이 존재하는지, 그 table에서 어떤 column을 넣어줄지 설정을 해줌

view에서 온 요쳥을 토대로 DB에서 data를 가지고옴

views.py

혹은 client가 보낸 request객체를 가지고와서
무엇이 필요한지, 어떤 걸 가지고 와야 할지 model에게
django manager를 통해 전달해줌

왜 model을 거쳐야 할까?

model이 어떤 정보를 가지고 올지 정확한 위치를 알기 때문에
model을 거쳐 DB에서 가지고 옴

Django Database

기본적으로 장고는 sqlite3라는 데이터 베이스를 제공하는데
특별한 일이 없는 이상 각자의 상황에 맞게 DB를 가지고와서 사용한다

장고는 RDBS ( 관계형 데이터베이스 ) 를 사용하고,
Django ORM을 통해 데이터베이스에서 가지고 올 데이터를 정해준다

Database 설정

mysql을 켜준뒤 데이터 베이스를 만들고 NAME칸에 만들어준 데이터 베이스를 넣어 준다

중간에 오타가 났는데...

CREATE DATABASE databaseName

명령어를 통해 데이터베이스를 만들어 준뒤

SHOW DATABASES;

명령어를 입력해서 만들어 졌는지 확인

mysql을 통해 확인 하고 싶다면

USE databaseName

아직 마이그레이션을 안해주어서 테이블이 비어있지만
연결해준 뒤, 모델을 작성하고 DB에 넣어 주면 됩니다

Django lifecycle

위에 장고가 어떻게 MTV와 비슷하지만 조금 더 보충 할 부분이 있어서 넣었습니다

wsgi.py

웹서버와 로직사이를 연결해주는 인터페이스

wsgi

W eb
S erver
G ateway
I nterface

파이썬에서 웹서버와 통신을 하기 위한 인터페이스 입니다

middleware

settings.py에서 추가, 변경이 가능하며
http request를 처리하기전 거치는 관문입니다

middleware가 적혀져있는 순서대로 진행됩니다

settings.py에서 이런식으로 존재하고 있습니다

urls.py

request와 매칭되는 callable object를 반환하여 실행
장고에서는 view에서 작성한 것들을 가지고 와서 url에 코드를 작성하고
template를 통해 유저에게 보여집니다

이 과정에서 view는 크게 두가지로 나뉘는데

Function Based View
Class Based View

위 두가지 이며, django에서 논쟁거리중 하나입니다

FBV를 써야한다, 아니다 CBV 써도 괜찮다

전.. 필요에 따라 필요한 걸 골라써 쓰는게 맞지 않나 싶습니다
굳이 하나만 고집하기 보다는 유연하게 대처를 하는게 맞다고 생각합니다

views.py

CBV라면 dispatch 메서드를 통해 request를 처리할 함수를 선택

class UserLogin(views.View):
	def get(self, request):
    .
    .
    	def post(self, request):
    .
    .

이런식으로 get일때 post일 때를 나눠 각각 처리해 줍니다
실행하면서 models.py를 통해 필요한 데이터를 가지고 옵니다

middleware

Response는 다시 미들웨어를 거치는데
이번에는 적혀있는 순서를 역순으로 실행하면서 마칩니다

wsgi.py

이렇게 온 response를 인터페이스를 통해 웹서버에 전달 됩니다

---

장고를 시작하는 법은 아니고
어떻게 장고가 실행이 되고, 유저가 보는 화면은 어떤 루트를 통해
request되고 response 되는지 알아봤습니다

Django를 시작하시는 분들께 도움이 됬으면 좋겟습니다
감사합니다 😁