1장.md

장고 개발의 기본 사항

• 장고는 MTV(Model-Template-View)에 따른 일정한 룰에 의해 진행된다.
• 단축 함수, 제네릭 뷰 등 필요한 기능들을 미리 만들어 두었다.
• 해외에서 가장 많이 사용되는 파이썬 웹 프레임워크라서 레퍼런스가 많다.

1.1 MTV 개발 방식

• 자바 웹 프로그래밍의 MVC 방식과 거의 동일한 개념이다.
• 테이블을 정의하는 모델 사용자가 보게 될 화면의 모습을 정의하는 템플릿 애플리케이션의 제어 흐름 및 처리 로직을 정의하는 뷰로 구분해서 개발한다.
• 이렇게 나눠서 진행하면 모듈 간의 독립성을 유지할 수 있고, 느슨한 결합(Loose Coupling) 설계의 원칙에도 부합합니다.
• DB 설계자, 디자이너, 응용 개발자 간에 협업도 쉬워진다.
• 장고에서 프로젝트를 생성하기 위해 startproject 및 startapp 명령을 실행하면, 자동으로 프로젝트 뼈대에 해당하는 디렉터리와 파일들을 만들어준다.
• 모델은 models.py 파일에, 템플릿은 telmplates 디렉터리 하위의 *.html 파일에, 뷰는 views.py 파일에 작성한다.

1.2 MTV 코딩 순서

• 모델, 템플릿, 뷰 셋 중에서 무엇을 먼저 코딩해야 하는지에 대해 정해진 순서는 없다.
• 단, 독립적으로 개발할 수 있는 모델을 먼저 코딩하고, 뷰와 템플릿은 서로 영향을 미치므로 모델 이후에 같이 코딩하는 것이 일반적이다.
• 뷰와 템플릿의 코딩 순서도 굳이 정할 필요도 없지만, 필자는 템플릿을 먼저 코딩함
• 다만 클래스형 뷰(CBV)처럼 뷰의 코딩이 매우 간단한 경우에는 뷰를 먼저 코딩하고 그 다음에 템플릿을 코딩함.

정리하면 다음과 같다.

• 프로젝트 뼈대 만들기: 프로젝트 및 앱 개발에 필요한 디렉터리와 파일 생성
• 모델 코딩하기: 테이블 관련 사항을 개발(models.py, admin.py 파일)
• URLconf 코딩하기: URL 및 뷰 매핑 관계를 정의(urls.py 파일)
• 뷰 코딩하기: 애플리케이션 로직 개발(views.py 파일)
• 템플릿 코딩하기: 화면 UI 개발(templates/ 디렉터리 하위의 *.html 파일들)

1.3 settings.py 주요 사항

다음 항목들은 프로젝트 개발 시 필수 사항이므로, 장고가 자동으로 사항을 확인해서 필요하다면 수정해줘야 함

• 데이터베이스 설정: default로 SQLite3 지정
• 템플릿 항목 설정: TEMPLATES 항목으로 지정
• 정적 파일 항목 설정: STATICS_URL 등 관련 항목을 지정
• 애플리케이션 등록: 프로젝트에 포함되는 앱은 모두 설정 파일에 등록해야함
• 타임존 지정: 최초에는 UTC(세계표준시)로 설정되어 있는데, 한국 시간으로 변경해야함

settings.py 파일에 어떤 항목이 정의되어 있는지 자주 확인해보기를 권장

1.4 models.py 주요 사항

• 테이블을 정의하는 파일
• 장고의 특징 중 하나로, 데이터베이스 처리는 ORM(Object Relation Mapping)기법을 사용
• 테이블을 클래스로 매핑해서 테이블에 대한 CRUD 기능을 클래스 객체에 대해 수행하면 장고가 내부적으로 데이터베이스에 반영함
• ORM 기법에 따라 테이블을 하나의 클래스로 정의하고 테이블의 컬럼은 클래스의 변수(속성)로 매핑함
• 테이블의 신규 생성, 테이블의 정의 변경 등 models.py 파일에서 데이터베이스 변경 사항이 발생하면, 이를 데이터베이스에 실제로 반영해주는 작업을 해야함
• 이를 위해 migration이란 개념을 도입함
• migration이란 테이블 및 필드의 생성, 삭제, 변경 등과 같이 데이터베이스에 대한 변경 사항을 알려주는 정보입니다.
• 물리적으로는 앱 디렉터리별로 migrations/ 디렉터리 하위에 마이그레이션 파일들이 존재함
• 장고는 이런 migration 정보를 이용해 변경 사항을 실제 데이터베이스에 반영하는 makemigrations 및 migrate 명령을 제공함

1.5 URLconf 주요 사항

• URLconf 용어는 URL과 뷰를 매핑해주는 urls.py 파일을 의미
• 프로젝트 전체 URL을 의미하는 프로젝트 URL과 앱마다 정의하는 앱 URL 2계층으로 나눠서 코딩하는 방식을 추천함
• 이 방식은 URLconf를 계층적으로 구성하므로 변경, 확장이 쉽다.

이러한 장점이 있다.

• 이미 개발해 놓은 앱을 다른 프로젝트에서 사용하는 경우에도 urls.py 파일을 수정 없이 재활용할 수 있음
• URL 패턴별로 이름을 지정할 수 있고, 패턴 그룹에 대해 namespace를 지정할 수 있음
• reverse() 함수나 {% url %} 템플릿 태그를 사용해, 소스에 URL을 하드 코딩하지 않아도 됨

1.6 views.py 주요 사항

• views.py는 뷰 로직을 코딩하는 가장 중요한 파일임
• 프로젝트 개발 범위가 커짐에 따라 로직도 점점 복잡해지고 views.py 파일의 코딩 량도 많아짐.
• 즉, 가독성과 유지보수 편리, 재활용 등을 고려해야 한다는 점이 중요
• 뷰 로직을 함수로 코딩할 것인지 클래스로 코딩할 것인지에 따라 함수형 뷰(Function-based-view) 와 클래스형 뷰(Class-based view) 로 구분함
• 필자는 클래스 형 뷰를 자세히 공부하기를 권장함
• 단축함수, 클래스형 제네릭 뷰와 같이 다른 프레임워크에 비해 뷰 작성에 편리한 기능을 많이 제공함

1.7 tenplates 주요 사항

• 웹 화면(페이지)별로 템플릿 파일(*.html)이 하나씩 필요하므로, 이런 템플릿 파일들을 모아두기 위한 템플릿 디렉터리가 필요함
• 프로젝트 템플릿 디렉터리는 TEMPLATES 설정의 DIRS 항목에 지정된 디렉터리임
• 앱 템플릿 디렉터리는 각 앱 디렉터리마다 존재하는 templates/ 디렉터리임
• 프로젝트 템플릿 디렉터리에는 base.html 등 전체 프로젝트의 룩앤필에 관련된 파일들을 모아두고, 각 앱에서 사용하는 템플릿 파일들은 앱 템플릿 디렉터리에 위치 시킵니다.

예를 들어, mysite 프로젝트에서 bookmark 앱을 개발한다면, 일반적인 경우 템플릿 디렉터리는 다음과 같다.

• 프로젝트 베이스(루트) 디렉터리: /home/shkim/pyDjango/ch2/

• 프로젝트 디렉터리: /home/shkim/pyDjango/ch2/mysite/

• 프로젝트 템플릿 디렉터리: /home/shkim/pyDjango/ch2/templates/

• 앱 템플릿 디렉터리: /home/shkim/pyDjango/ch2/bookmark/templates/

• 프로젝트 템플릿 디렉터리를 먼저 검색하고 그 다음 앱 템플릿 디렉터리를 검색한다.

• 앱 템플릿 디렉터리도 각 앱마다 하나씩 여러 개가 존재하는데, INSTALLED_APPS 설정 항목에 등록된 순서대로 검색함

1.8 Admin 사이트

• Admin 사이트는 테이블의 내용을 열람하고 수정하는 기능을 제공함
• User, Group 테이블을 포함해, 앞으로 우리가 만드는 테이블에 대한 데이터의 입력, 수정, 삭제 등의 작업을 할 수 있음
• User와 Group 테이블이 보이는 것은 이미 settings.py 파일에 django.contrib.auth 앱이 등록되어 있기 때문임
• Admin 사이트에 원하는 테이블을 등록하기 위해서는 admin.py 파일에 작업하면 됨

1.9 개발용 웹 서버 - runserver

• 개발 과정에서는 작성된 코드를 실행하고 테스트하는 과정이 필요함
• 개발 과정에서 현재 웹 프로그램을 실행해볼 수 있도록 runserver라는 테스트용 웹 서버를 제공함
• 실제 고객에게 오픈하는 상용화를 고려한다면, Apache 또는 Nginx 등의 상용 웹 서버를 사용해야 함
• runserver는 처리 능력, 보안이 부족함

퇴근 후 8시 역삼 커피빈에서