저번 글에서 settings.py파일에 대해서 하나하나 분석을 해봤었다. 생각보다 많은 특징들이 있었는데 이번에는 그 편에 이어서 다른 파일들에 대해서 분석을 해보겠다.
1. urls.py
파일명 그대로 url에 대해서 관리하는 파일이다.
저번 글에서 확인했다시피 startproject로 생성되는 urls.py는 settings.py에서 ROOT_URLCONF로 지정되어 장고 내에 존재하는 모든 urls.py의 최상위 파일이 된다.
startapp으로 최초로 앱을 만들었을 때는 urls.py가 없으므로 사용하려면 앱애서 다루려면 직접 만들어주어야 한다.
#config > urls.py
from django.contrib import admin
from django.urls import path, include #include 추가
from posts import views
urlpatterns = [
path('admin/', admin.site.urls),
path('',views.home, name='home'),
path('post/', include('posts.urls')),
#post/로 끝나는 url은 posts앱 안의 urls.py에서 다룸
]위에 처럼 include키워드를 이용해서 다른 앱에 있는 urls.py를 불러와 사용할 수도 있다.
#posts > urls.py
from django.urls import path
from posts import views as post_views
#posts앱에서 불러오는 views를 "post_views"라는 이름으로 사용한다
urlpatterns = [
path('create/',post_views.postform, name='create'),
path('list/',post_views.postlist, name='list'),
]
이렇게 사용할 경우
- 127.0.0.0:8000/home
- 127.0.0.0:8000/post/create/
- 127.0.0.0:8000/post/list/
이 3가지 경로를 통해 view와 template에 접근할 수 있다.
drf를 사용하면 router이용할 수도 있는데 이 부분은 추후에 다루겠다.
2. asgi.py, wsgi.py
2-1. asgi.py
생긴게 wsgi와 비슷하게 생겼고 마찬가지로 아직 개발을 하면서 직접 파일을 다뤄보진 않았었다.
ASGI에 대해서 간단하게 알아보자면 다음과 같다.
ASGI: "Asynchronous Server Gateway Interface"의 줄임말로 WSGI의 상위 개념으로 설계되었으며 WSGI와 다르게 요청을 비동기식으로 처리한다.
즉, WSGI의 상위호환이라고 생각하면 이해하기 쉽다. WSGI와 마찬가지로 웹서버와 파이썬 웹 프로그램의 통신을 도와주는 middleware라고 생각하면 된다.
단, WSGI는 요청을 동기식으로 처리하지만 ASGI는 요청을 비동기식으로 처리한다는 차이점이 존재한다. 동기식과 비동기식에 대해서 헷갈린다면 이 영상을 참고하자.
2-2. wsgi.py
저번 글에서 이미 wsgi에 대해서 대략적으로 다뤘기 때문에 넘어가겠다.
asgi와 wsgi 모두 python의 CGI, Common Gateway Interface라고 볼 수 있는데 자세한 내용은 이 글을 참고하기 바란다.
결론적으로는 두 파일 모두 배포를 할 때 쓰인다고 볼 수 있으며 이 부분에 대해서는 나중에 다뤄보도록 하겠다.
3. __init__.py
이 파일은 막상 열어보면 아무러 내용도 존재하지 않는다. __init__.py는 사실 장고보다는 파이썬에 관련된 사항인데 하나의 폴더를 패키지로 인식하고 사용할 수 있게 해주며 이름 뜻 그대로 패키지를 초기화하는 역할도 한다고 한다.
실제로 프로젝트를 만들다보면 폴더안에 __init__.py가 하나 씩 존재하는 것을 알 수 있다. 그로 인해 파이썬은 폴더를 하나의 패키지로 인식하게 되는 것이다.
4. admin.py
파일 명칭과 똑같이 관리자 사이트를 관리하는 파일이다. 장고에서는 우리가 만드는 사이트들에 대해서 자동적으로 관리자 사이트를 만들어준다. admin.py는 그 관리자 페이지에 관한 정보를 다룬다.
아래 명령어를 사용하면 관리자 사이트에 로그인 할 수 있는 관리자 계정이 만들어진다.
python manage.py createsuperuser그 후 아래와 같이 최상위주소에서 /admin으로 들어가면 관리자 페이지가 나오게 된다.
127.0.0.1:8000/admin이 관리자 사이트의 존재로 인해 간단한 프로젝트 정도는 우리가 직접 DB안을 하나하나 뜯어볼 필요가 없다.
아래와 같이 Models.py에서 만든 모델을 admin.py안에 등록하면 관리자 사이트에서 모델에 들어있는 정보를 확인할 수 있다.
#Posts > admin.py
from django.contrib import admin
from .models import Post
admin.site.register(Post) #admin사이트에 우리가 앱에서 만든 모델을 등록
Posts로 들어가면 우리가 저번에 글 작성폼을 사용하여 등록하였던 글들이 나온다.
이렇게 내용도 확인할 수 있다.
위와 같이 사용자들이라는 항목도 확인 가능한데 현재 우리가 만든 qwer이라는 계정이 관리자계정으로 등록되어있는 것을 확인할 수 있다.
이 부분도 중요할 수 있는데 저곳에는 기본 UserModel 혹은 커스텀한 UserModel을 사용하여 회원가입을 만들었을 때 회원가입한 사용자의 정보 역시 저 안에 뜨게 된다.
이 부분은 추후에 회원가입/로그인을 다룰 때 확인할 수 있을 것이다.
5. apps.py
스택오버플로우에서 찾아본 내용에 따르면 다음과 같다.
apps.py
This file is created to help the user include any application configuration for the app. Using this, you can configure some of the attributes of the application.
이 파일을 사용해서 우리가 생성한 앱의 속성들을 구성할 수 있다.
기본으로 생성된 코드를 살펴보자.
#posts > apps.py
from django.apps import AppConfig
class PostsConfig(AppConfig):
default_auto_field = 'django.db.models.BigAutoField'
name = 'posts'PostsConfig라는 클래스를 AppConfig라는 클래스를 상속해서 사용하는 것을 확인 할 수 있다.
공식문서를 확인하면 다음과 같은 설명이 나온다.
AppConfig
Application configuration objects store metadata for an application.
Some attributes can be configured in AppConfig subclasses. Others are set by Django and read-only.우리가 생성한 앱에 대한 메타데이터를 저장하며 일부 속성들에 대해서는 sub클래스에서 구현할 수 있다고 한다.
지금까지 내용들을 정리하면 다음과 같다.
우리가 앱을 생성하면 apps.py와 그 안에 Appconfig를 상속받은subclass가 자동적으로 생긴다.
그리고 그 안에서 default_auto_field와 name이라는 속성이 자동적으로 정의되며 다른 특정 속성들도 이 클래스에서 구성할 수 있다는 것이다.
이 apps.py도 사실 개발을 하면서 많이 건들지는 않은 파일이다. 나같은 경우는 AppConfig의 ready메소드를 오버라이딩해서 사용한 적 말고는 없는 것 같다.
6. tests.py
장고는 공식 문서에서도 테스트의 중요성을 엄청나게 강조한다. 나 역시 테스트는 많이 할수록 좋다는 것은 알고 있었다. 하지만 막상 지금 진행했던 프로젝트들 모두 시간에 쫓겨서 바로바로 구현하는것에 그쳤던 것 같다.
주로 shell을 이용하거나 postsman을 사용해서 테스트를 진행하긴 했는데 사실 시간도 오래 걸리고 이미 완성된 코드를 가지고 테스트를 진행하는 것이기 때문에 디버깅이 상당히 까다로웠다. 장고에서는 unit test를 지원하며 이에 따라 우리가 view나 model에 작성한 함수를 테스트할 수 있다.
보통은 tests.py의 원형을 그대로 사용하는 것이 아닌 앱 내에 tests라는 디렉토리를 만들고 그 안에 테스트파일들을 관리한다.
이 글에 자세히 나와있기 때문에 참고하면 좋을 것 같으며 나중에 test에 대해서는 다른 포스팅으로 다뤄볼 예정이다.
7. migrations 폴더
이 폴더에는 우리가 python manage.py makemigrations를 통해 model의 변경사항에 대한 파일이 이곳에 만들어진다.
이 안에 0001_initail.py가 makemigrations를 최초로 실행했을 때 생성되는 파일이며 이 안을 살펴보면 다음과 같다.
# posts > migrations > 0001_initail.py
# Generated by Django 4.0.6 on 2022-07-26 14:15
from django.db import migrations, models
class Migration(migrations.Migration):
initial = True
dependencies = [
]
operations = [
migrations.CreateModel(
name='Post',
fields=[
('id', models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
('title', models.CharField(max_length=20)),
('description', models.TextField()),
],
),
]확인해보면 Migration클래스안에 dependencies와 operations가 리스트로 선언되어있다. 이 리스트들에 대해 살펴보면 다음과 같다.
operations:migration시 작동할 메소드가 들어간다고 생각하면 된다.
모델을 변경하고makemigrations를 하면 그에 따른 변경사항이 저 안에 메서드로 자동적으로 지정된다.
dependencies: 단어의 뜻에 맞게 우리가migration을 실행할 때 반드시 적용되어야 하는 파일이 이 안에 담기게 된다.
위의 예에서는 처음migration을 진행했기 때문에 비어있지만 두번째부터는 저 안에 먼저 적용되어야 하는 파일이 안에 들어가 있을 것이다.
사실 모델을 많이 변경하다보면 migration이 정상적으로 이루어지지 않거나 DB관련 오류가 발생하는 경우가 많다.
이때 어설프게 파일을 수정하는 것 보다 배포 전이라면 migrations디렉토리 안의 파일을 모두 삭제하고 DB도 삭제한 다음 다시 수행하는 것이 훨씬 빠르게 조치된다.
나도 migrations디렉토리 안에 무슨 파일이 있는지 알지도 못한 채 싹 다 지우고 다시 migrate를 하곤 했었는데 적어도 무슨 역할을 하는지 이해 정도는 하는 것이 좋다고 생각한다. 자세한 내용은 이 글을 참고해보자.
8. 총정리
views.py, models.py에 대해서는 굳이 다루지 않아도 목적이 뻔하고 많이 다룰 것이기 때문에 따로 정리하진 않았다.
저번에 MVC패턴, MTV패턴에 대해서 조사할 때 단점으로 Controller, 즉 View 부분이 비대해진다는 단점이 있다고 찾아본 적이 있었다.
우리가 장고로 개발을 진행하다보면 대부분의 시간을 views.py라는 파일 안에서 시간을 보내게 될 것이다.
나 역시도 그랬었고 언젠가 장고 내의 다른 파일들에 대해서 알아볼 필요성을 느꼈었다. 장고에서 기본으로 생성하는 파일들인데 그에 대한 이유가 있을 것이라고 생각했다.
개발을 하기전에, 아니면 개발 중간에 이렇게 한번 짚고 넘어가는 것도 나쁘진 않은 것 같다.
