코린이형준

6. 장고에서 모델 이용하기

- 모델은 장고 프로젝트에서 토대가 되는 부분이다. 성급하게 모델을 작성하게 되면 어느 순간 프로젝트가 내생각과 다르게 흘러가는 경험을 하게 될것이다.

- 그렇기 때문에 모델은 신중히 미래를 고려하여 설계해야만 한다.

6-1. 앱을 분리하자

- 모델이 너무 많으면 앱을 나눠야 한다. 하나의 앱에 모델이 20개 이상있으면 너무 많은 일을 한다는것을 반증하는 것이다. 책에서는 모델 5개가 넘지 않길 권장한다.

6-2. 모델 상속에 주의하자

6-3. 장고 모델 디자인

- 정규화 하기 -> 데이터베이스 자체의 정규화에 대한 지식습득이 먼저다! 이 원칙에 맞춰 디자인을 해야만 한다.

- 캐시와 비정규화

    -적절한 위치에서 캐시를 세팅하는 것은 모델을 비정규화 할 때 발생하는 문제점들을 상당부분 해결해준다.

- 반드시 꼭 필요할때만 비정규화를 하도록한다.

-언제 널을 쓰고 언제 공백을 쓸것인가?

-정리

이외에도 모델에 관한 부분은 수많이 있으며 또한 two scoops of django에도 굉장히 자세히 다루고 있다. 제필요성에 의해서 필요한 부분만 적어둔거기 때문에 따로 웹서핑이든 도서를 통해 계속해서 학습을 해야하는 파트라고 생각됩니다!

5. Settings와 requirements 파일

장고 세팅 모듈에서는 수많은 항목의 설정을 제공하고 있다. 이것이 장고의 장점이자 어려움이 될 수 있다.

책에서 추천하는 장고 최적의 설정 방법은 아래와 같다.

- 버전 컨트롤 시스템으로 모든 설정 파일을 관리해야 한다.

- 반복되는 설정들을 없애야 한다.

- 암호나 비밀 키 등은 안전하게 보관해야 한다.

5-1.버전 관리되지 않는 로컬 세팅은 피하도록 한다.

- django의 시크릿키와 같은 것들은 공개 되서는 안되기 때문에 감춰줘야한다.

- 디버깅 툴과 같은 것은 운영 서버에서는 활용 되지 않고 개발 환경에서만 활용 되기 때문에 제외해야 한다.

- 즉, settings모듈을 분리해냄으로써 해결 가능한 부분이다.

5-2. 여러 개의 settings 파일 이용하기

- 한개의 settigns파일만 사용하는 것이 아닌 용도에 맞게 settings 파일을 분리해낸다.

settings/
    __init__.py
    base.py # 프로젝트의 모든 인스턴스에 적용되는 공통 세팅 파일
    local.py # 로컬환경에서 작업할때 사용(디버그, 로그 레벨, etc...)
    staging.py # 실운영 환경에 넘어가기전 반 운영 환경용 세팅 파일
    test.py # 테스트 러너, 로그 세팅을 위한 파일
    production.py # 실 운영 서버를 위한 세팅 파일

- 각 settings 파일 실행 명령어는 아래와 같다.(config는 프로젝트 명이다)

python manage.py runserver --settings=config.settings.local

- 각 세팅파일의 들어가는 코드의 차이는 개인적인 것이지만 공통적으로 DEBUG는 분리해줘야한다. 개발=True, 배포=False는 기본적으로 지켜줘야하는 분명한 사실이다.

- 그외의 실질적인 분리방식은 아래 링크를 참고 해도 될듯싶다!(깨알 깃허브 홍보ㅎ)

5-3. 코드에서 설정 분리하기

- secret key, aws key, api key와 같은 다른 사람들이 알아선 안되는 키값같은 경우, 분리해서 감춰야만 한다.

- 이를 해결하는 방식은 json, .env파일과 같은 형식으로 관리할 수있다.

- 하지만, 환경변수도 한가지 방식이고 확장에 용이하므로 알아보면 좋다.

- 이부분은 너무나 방식이 다양하여 책을 구입하여 참고하거나 구글에서 검색해보길 권장한다.

5-4. 여러개의 requirements파일 이용하기

- 환경이 여러개로 분리되면 각각에 해당하는 requirements를 생성해야한다.

- respository_root 아래에 아래와 같은 구조로 관리할 수 있다.

requirements/
    base.txt
    local.txt
    staging.txt
    production.txt

- 각 settings 파일과 동일한 이름으로 생성해준다.

- 설치는 아래와 같이 한다. -> 그에 맞는 가상환경 생성은 기본이다!!

pip install -r requirements/local.txt

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의 실질적인 동작을 이루는 프로젝트 소스외에 배포 및 문서에 관련된 것들로 이루어진다.

- 중간 레벨: 프로젝트 루트

    -장고 프로젝트 소스들이 위치하는 디렉터리로 모든 파이썬 코드들이 위치한 곳이다.

-최하위레벨: 설정 루트

    -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

- 간단히 용어 정의를 하자면