[Django] 내가 이해한 전체적인 flow, urls.py, views.py, models.py, django shell (+ 0717 1차 수정)

Overall Flow

(Client의) request —> Project url —> (include된걸로) App url —> SignInView(create, filter, get) —> Database —> 들고 다시 [views.py]—> Frontend로 해당 request에 대한 요청 값을 돌려 보내줌 (return)

하나씩 하나씩 보기

0. manage.py: 명령어 기준단. makemigrations, migrate, shell, runserver 등등의 명령어들은 터미널에서 ls 명령어를 찍어 manage.py가 있는 단에서 작성해야한다.

• python manage.py makemigrations: 모델스파이에서 수정이 있을 경우 반드시 쳐야하는 명령어 (ex. initial 0001)
• python manage.py migrate: migrations 속에 정보를 넣어 실제 DB에 적용
• python manage.py showmigrate: 이미 migrate가 적용된 파일은 [X]로, 그렇지 않은 파일은 [ ]로 표현되어 있음.

( + 🐜 1차수정)

만일 내가 내 깃헙 웹에 있는 기존의 repo를 재사용하고 싶을 때도, 이 manage.py가 있는 단에서 git remote or git clone을 해야 함.

1. urls.py
   

• 위의 사진은 프로젝트 자체의 urls.py (여기에서 임포트 주의: include, path. include이 메 소드가 프로젝트의 url과 앱의 url을 연결하는 것)
  
• 위의 사진은 앱 내의 urls.py 사진 (그래서 import에 SignUp, SignIn이 있음)
• 장고가 기본적으로 지원해주는 모듈인 path를 django.urls에서 임포트하며, views.py에서 SignUp과 SignIn 클래스를 모두 임포트해야, 올바르게 그쪽으로 요청을 보내서 함수를 쓸 수가 있다.
• 실제 프론트가 요청을 보냈을 때 가장 먼저 어디로 보낼지 판단하는 곳이며 (클래스로 진입하기 위한 진입 메소드를 제공)
• 위의 말을 다른 말로는 이렇게도 써 놓음:
  ""프론트가 보낸 리퀘스트에 대해서, 그 리퀘스트에 해당하는(합당한) 함수를 찾아서 해당 리퀘스트를 그 함수가 있는 곳으로 적절히 보내줘야 하는데, 그 합당한 함수를 찾아 보내주는 곳이 바로 여기. (리퀘스트의 경로를 찾아 던져주는 곳)""
• 근데 project와 app에 둘 다 urls.py가 있는데 그 둘 중 project에서 먼저 url을 받아서 어디로 갈지 결정. 그래서 project내의 urls.py에 include를 import하는 것
• 프론트와 백의 연결 통로, 통신 통로

2. models.py
   

• 1) 데이터 구조를 작성하고, 2) 데이터 타입을 결정하며, 3) 데이터 사이의 연관성을 지어준다.
• 데이터를 꺼내오는 작업 자체는 views.py가 하지만 실제로 데이터와 가장 친숙한 단. 즉, 데이터 표를 생성하고 views.py가 데이터를 알아서 꺼내갈 수 있도록 해주는 곳. 이것이 models.py를 보통 가장 먼저 작성하는 이유이기도 함. (데이터, 로직 등이 이곳에 들어와 제일 먼저 기본이 되어야 프론트랑 연결을 할래도 하고 그럴테니까)
• 이런 models.py에서 클래스를 하나 생성한다는 것은 그것이 곧 미래의 표(테이블)가 될 것이라는 의미. 그 클래스의 한 줄 한 줄은 표에서 하나 하나의 컬럼이 될 것.
• 사진의 line 1: 'django.db에 기본적으로 사용할 수 있는 모듈인 models를 임포트해와서 사용하겠다, 즉 내가 아래 적는 클래스에 들어가는 정보들은 모두 그 모듈에 의해 알아서 테이블화 될 것이다'의 의미. migrate 해서 MySQL에 DB가 만들어지면 그걸 다시 임포트 해와서 여기서 사용.
• 장고가 원래 제공해주는 Models.model 클래스 안에는 여러가지 함수들, 속성들이 들어있음.
• Meta 클래스: 테이블에는 보통 이름이 있는데 이 표에 내가 원하는 이름을 정해주기 위해서 선언하는 클래스. (모델스파이 안에 있음)
• def (__str__): 스페셜 메소드. 모델스파이를 통해 만든 객체(인스턴스)가 하나하나 생길 때 대표적으로 어떤 값을 반환할지를 명시.
• models.py에서 만들었던 클래스를 임포트함 (맨 위에 줄)

3. views.py
   

• 실제 그 리퀘스트를 던짐 받는(...)곳. 함수를 짜놓은 실제 로직부분이 있는 곳 (어느 부분을 프론트한테 주고 그럴지 뭐 이런거)
• 그래서 이 뷰스파이 안에는 프론트 리퀘스트를 받는것을 적어줘야하는데 그게 대표적으로 get, post가 대표적인 것: get은 DB정보를 가져가기만 하고, post는 DB를 실제로 수정, 저장, 삭제가 가능한 것
• 뷰 안에 있는 클래스의 이름은 기능을 바로 알 수 있도록 만드는 것이 중요
• import 시의 HttpResponse: 별다른 메시지가 필요하지 않을 때 사용, JsonResponse: json 데이터 형식으로 뭔가 메시지를 표현할 때 사용
• git commit은 수시로 해주어야 한다. (이건 views.py 뿐 아니라 모든 곳에 적용)

4. Django shell

• models.py에 저장되어, DB화된 데이터를 불러오거나 할 때 사용
• 반드시 manage.py가 있는 층위에서 불러내야 한다(python manage.py shell)
• from [앱이름].[models] import [클래스명] 으로 시작한다
• 이 날 배운 메소드: Users.objects.all(), Users.objects.values(), Users.objects.get(), Users.objects.filter(), Users.objects.create()
• Users.objects.get()과 Users.objects.filter()의 차이:
  위 사진을 보면 이해할 수 있음. (filter은 b, get은 c로 변수 처리해놓은 상황)
  1) filter는 앞에 QuerySet이 있고(리스트형 반환) get은 앞에 없음(객체 자체 반환)
  2) filter는 다수의 객체가 결과 값으로 나올 수 있지만, get은 기본적으로 하나만 보여주기 때문에 위의 사진에서 보다시피 맨 마지막 줄에서 get() returned more than one Users -- it returned 2!라는 에러가 나고 있다.
• Users.objects.all()과 Users.objects.values()의 차이:
  
  우선 공통점은 둘 다 모든 객체를 보여준다는 점
  그런데 all은 이름만 보여주는거, values는 모든 정보 다 보여주는 것 (내가 모델스파이에 넣은)
  그런데 지금 사진을 보면 내가 Users.objects.values()[0] 즉, 인덱스 0에 해당하는 (가장 첫번째 정보에 해당) 값만 출력해달라고 요청했기 때문에 Users object (1)에 해당하는 정보만 모두 출력된 것. [] 형식으로(인덱스 형식) 요청하는 것은 values()는 딕셔너리를 요소값으로 취하는 set형 자료임을 알 수 있다.
• Users.objects.filter(조건문).exists():
  쿼리셋이 비어있으면 False, 안 비어있으면 True 반환

기타

• 데이터 베이스라는 말 자체는 사실 테이블(표)의 집합체
• 장고 시작 단계에서 이게 대체 뭐야... 싶을 때는 찍어보면(print) 뭔지 보이니까 그냥 무조건 찍어볼 일이다
• 겉Url(프로젝트 속의 urls.py) & 속Url(앱 속의 ursl.py) & settings.py 서로 상호작용하면서 원하는대로 유알엘 던져주고 그런거임
• URL 때 슬래시 문제: http://localhost:8000/account/sign-in에서 맨 마지막에는 /는 안써도 되고요
• as_view(): 버그같은거 있는지 한 번 확인하는 장고 내장 메소드
• HTTP 세션 당시 request의 구조: start line, headers, body로 나뉘는데 우리(Q. 가 누구지?)는 body를 봐야함
• GET 메소드에는 바디가 없고 POST메소드에는 바디가 있음(그 내용을 보고 우리가 내용을 디비에서 가져오는 것)
• 파이썬은 모든것이 객체니라
• QuerySet과 객체의 차이가 정확히 뭘까? A: QuerySet은 객체의 리스트 라고 생각하면 좋겠다!

향후 수정 계획 많음.

references & huge Thanks to:
https://velog.io/@solseye