
3. 어떻게 장고 프로젝트를 구성할 것인가
3-1. 장고의 기본 프로젝트 구성
- 장고의 기본명령어를 실행하면 그리고 대부분의 나와같은 토이프로젝트만 만들던 신입 개발자들은 아래와 같은 프로젝트 구성이 되어 있을것이다.
mysite/
manage.py
app/
__init__.py
admin.py
urls.py
views.py
models.py
tests.py
mysite/
__init__.py
settings.py
urls.py
wsgi.py
asgi.py
-하지만, 이는 여러 소스코드가 이곳저곳 존재할 실무에서는 혼동을 주기 쉬운구조로 이책에서는 아래와 같은 방식을 제안한다.
mysite_project/
.gitignore
Makefile
Dockerfile
docs/
README.md
requirements.txt
mysite/
manage.py
media/ #개발전용
static/
templates/
app/
config/
__init__.py
settings/
base.py
deployment.py
development.py
urls.py
asgi.py
wsgi.py
- 총 3단의 구성으로 최상위레벨, 중간 레벨, 최하위 레벨로 나뉜다. 책에 정리된 것들을 적었으며 이것들 외에 성격이 비슷한 파일 및 디렉터리를 자신의 생각에 맞게 배치해두면 될것 같다!
- 최상위레벨: 저장소 루트
-djnago의 실질적인 동작을 이루는 프로젝트 소스외에 배포 및 문서에 관련된 것들로 이루어진다.
파일/디렉터리 | 설명 |
.gitignore | 깃이 처리하지 않을 파일과 디렉터리를 정의한것 |
README.md와 docs | 나외의 다른 개발자가 쉽게 프로젝트를 파악할 수 있도록 문서화한것 |
Makefile과 Dockerfile | docker와 같은 배포시 필요한 작업을 정리한 파일 및 이미지 |
requirements.txt | 장고의 패키지 버전 목록을 정리해둔파일 |
mysite/ | 프로젝트 소스 |
- 중간 레벨: 프로젝트 루트
-장고 프로젝트 소스들이 위치하는 디렉터리로 모든 파이썬 코드들이 위치한 곳이다.
파일/디렉터리 | 설명 |
config/ | 프로젝트의 설정 파일 즉, settings파일이 모여있는 디렉터리 |
manage.py | django를 동작시키는 명령어 파일(왠만하면 수정하지 않길 권장) |
media/ | 개발 용도로 이용되는 이미지 관련 디렉터리다 |
app/ | 개발간 확장할 users, post와 같은 app들을 의미한다. |
static/ | css, js, image등 사용자가 올리는 것 이외의 정적파일들 |
templates/ | 시스템 통합 템플릿 파일 저장 장소 |
-최하위레벨: 설정 루트
-django의 최종 url의 정의 및 설정 파일 wsgi설정 파일등 초기 프로젝트 생성시에 나오는 루트 디렉터리이다.
3-2.장고 쿠키커터
- 책에서는 쿠키커터를 추천해주는데 개인적으로 현재 많은 버전 업데이트가 이뤄지며 장고 자체로도 문제없다 생각되어 잘정리된 링크를 추천드립니다!!(two scoops of django책을 구매하길 추천해요!)
4. 장고 앱 디자인의 기본
4-1. 장고의 용어 정의
- 장고 개발을 할때 용어에 대해 간단히 정리하고 가야한다.
-장고 프로젝트: 장고 웹프레임워크를 기반으로 한 웹 애플리케이션을 지칭한다.
-장고 앱: 프로젝트의 한 기능을 표현하기 위해 디자인된 작은 라이브러리를 의미한다. 아래 명령어로 생성되는 디렉터리를 말한다.
python manage.py startapp <app_name>
-INSTALLED_APPS: 프로젝트에서 이용하려고 settings.py에 설정한 장고 앱들을 지칭한다.
-서티 파티 장고 패키지: 파이썬 패키지 도구들에 의해 패키지화된, 재사용 가능한 플러그인 형태의 장고앱을 지칭한다.
-코린이 TIPS! -> 책에 나오진 않았는데 나름 편한 방식이라 팁 전수하고 갑니다.
-네뭐.. 그렇다구요 나중에 앱이 많아질것 대비해서 미리 분리하고 가는것 매우 좋습니다 애용해주셔요ㅎㅎ
DJANGO_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]
PROJECT_APPS = [
'accounts',
'posts',
'notifications',
'teams',
'images',
]
THIRD_PARTY_APPS = [
'rest_framework',
'corsheaders',
'drf_yasg',
'django_extensions',
]
INSTALLED_APPS = DJANGO_APPS + PROJECT_APPS + THIRD_PARTY_APPS
4-2. 장고 앱 디자인의 황금률
- 장고 앱 디자인 즉, 정의는 각 앱이 그 앱의 주어진 임무에만 집중할 수 있도록 정의해야한다는 것이다.
- 아래와 같은 방식으로 앱은 그자체로 기능을 설명할 수 있어야합니다.
# 유저의 정보를 기록하고 저장하며 조회할수 있는 앱
users/
# 게시글을 기록하고 저장하며 조회할수 있는 앱
posts/
# 팀을 관리할수 있는 앱
teams/
- 추가로 개인적인 의견을 덧붙이자면 app을 분리했을때 독립적으로 존재할 수 기능을 할수 있는 단위가 분리의 단위라고 생각합니다.
-즉, post는 따로 제약사항 없이 생성이 가능하지만 comment의경우, post가 없다면 존재할 수 없는 기능이기 때문에 분리하지 않고 post내부에 comment를 속하게 개발합니다. -> 이것은 개인적인 개발 스타일 일뿐 꼭 따르지 않아도 됩니다!!(책내용 아니에요!)
4-3 장고 앱 이름 정하기
- flavors, animals, polls, dreams와 같이 앱 이름은 명료하게 지어야한다.
- 앱의 이름은 복수의 형태로 지어야한다.
- pep8의 규약에 맞게 앱 이름을 짓도록 하자. 소문자로 구성된 숫자, 대시(-), 마침표(.), 스페이스와 같은것들은 왠만해서는 넣지말자
- 밑줄(_)의 경우 가독성을 높이기 위해서 꼭 사용해야 한다면 사용하도록 하자
4.4 앱 안에는 어떤 모듈이 위치하는가?
- 공통 앱 모듈: 이미 오랜 시간 장고를 개발하며 장고 앱을 구성하는 오피셜한? 앱이름들이다.(이건 따르도록하자!)
app/
__init__.py
admin.py
management/
forms.py
migrations/
models.py
templatetags/
test/
urls.py
views.py
-비공통 앱 모듈
app/
behaviors.py
constants.py
context_processors.py
decorators.py
db/
exceptions
fields.py
factories.py
helpers.py
managers.py
- 간단히 용어 정의를 하자면
앱 이름 | 설명 |
behaviors.py | 모델 믹스인의 위치에 대한 옵션 |
constants.py | 앱레벨에서 이용되는 세팅을 저장하는 장소의 이름 |
decorators.py | 데코레이터가 존재하는 곳 |
db/ | 여러 프로젝트에서 이용되는 커스텀 모델이나 컴포넌트 |
fields.py | 폼 필드 이용에 사용되는 파일 |
factories.py | 테스트 데이터 팩토리 파일 |
helpers.py | 헬퍼 함수. 뷰와 모델을 가볍게 하기위한 |
managers.py | models.py가 너무 커질경우, 커스텀 모델 매니저를 옮기는 용도 |
signals.py | 커스텀 시그널 함수 저장소 |
'기술 > Django' 카테고리의 다른 글
two scoops of django - django에서 모델이란? (0) | 2022.09.01 |
---|---|
two scoops of django - settings와 requirements 파일 (0) | 2022.08.31 |
two scoops of django - django 코딩 스타일 맞춰보기 (0) | 2022.08.29 |
drf -서버란? 그리고 drf란? (0) | 2022.03.24 |
drf TDD 적용하기 (0) | 2022.01.31 |