Django & Design pattern

Web application 개발

→ 인터넷을 통해 사용자에게 제공되는 소프트웨어 프로그램을 구축하는 과정

 

• 웹의 동작 방식

웹 페이지를 보게 될 때까지 무슨 일이 일어나는가?

클라이언트 - 서버 구조

→ 클라이언트의 요청과 서버의 응답

 

클라이언트 : 서비스를 요청하는 주체 (웹 사용자의 인터넷이 연결된 장치, 웹 브라우저)

서버 : 클라이언트의 요청에 응답하는 주체 (웹 페이지, 앱을 저장하는 컴퓨터)

 

EX)

1. 웹 브라우저(클라이언트)에서 주소를 입력
2. 브라우저는 인터넷에 연결된 어딘가의 컴퓨터(서버)에게 주소의 html 파일을 달라고 요청
3. 요청 받은 서버 컴퓨터가 데이터베이스에서 파일을 찾아서 응답
4. 전달받은 파일을 사람이 볼 수 있도록 웹 브라우저가 해석해주면서 사용자가 보게 됨

 

프론트엔드 : 사용자 인터페이스를 구성하고 사용자가 앱과 상호작용할 수 있도록 한다.

ex) HTML, CSS, Javascript, 프레임워크 등

 

백엔드 : 서버 측에서 동작하며, 요청에 대한 처리와 데이터베이스와의 상호작용 등을 담당

ex) 파이썬, 자바, 백엔드 프레임워크, 데이터베이스, API, 보안 등

 

웹 서비스 개발에는 로그인, 로그아웃, 회원관리, 데이터베이스, 보안 등 많은 기술들이 필요하다.

개발자가 이 모든 것을 작성하기는 현실적으로 어렵지만, 모두 직접 만들 필요 없이 잘 만들어진 것들을 가져와서 활용할 수 있다!

 

• Framework

웹 애플리케이션을 빠르게 개발할 수 있도록 도와주는 도구

(개발에 필요한 기본 구조, 규칙, 라이브러리 등을 제공)

일종의 어떤 환경을 빌려쓰는 것!

 

Django → Python 기반의 대표적인 웹 프레임워크

 

• 가상 환경

Python 애플리케이션과 그에 따른 패키지들을 격리하여 관리할 수 있는 독립적인 실행 환경

 

1. 가상 환경 venv 생성

python -m venv venv(임의로 설정하는 가상환경 이름인데 보통 venv를 쓴다)

 

2. 가상 환경 활성화

source venv/Scripts/activate

(실제로 폴더 아래에 있는 파일, 하지만 환경에 들어가기 보다는 가상환경을 키고 끈다는 개념으로 이해하기)

• 가상 환경 비활성화 = 터미널에 ‘deactivate’ 입력

 

3. 환경에 설치된 패키지 목록 확인

pip list

 

프로젝트를 공동으로 진행할 때 원격저장소에 가상환경을 올리지 않기 때문에 팀원 간에 어떤 패키지를 설치했고 어떤 버전을 설치했는지 등 서로의 가상환경 상황을 알기 위해 가상 환경에 대한 정보 (패키지 목록)를 공유하게 된다.

 

• 의존성 패키지

한 소프트웨어 패키지가 다른 패키지의 기능이나 코드를 사용하기 때문에 그 패키지가 존재해야만 제대로 작동하는 관계

사용하려는 패키지가 설치되지 않았거나, 호환되는 버전이 아니면 오류가 발생하거나 예상치 못한 동작을 보일 수 있다.

 

4. 의존성 패키지 목록 생성

pip freeze > requirements.txt

→ 패키지 목록이 적힌 requirements 라는 텍스트 파일이 만들어진다!

→ requirements 말고 다른 이름도 가능하지만 하지 않는다! 파이썬 개발자들 사이에서 암묵적인 룰로 패키지 목록은 ‘requirements’ 를 쓰는 것으로 되어있기 때문!

 

• 의존성 패키지 관리의 중요성

개발 환경에서는 각각의 프로젝트가 사용하는 패키지와 그 버전을 정확히 관리하는 것이 중요

 

• Django 프로젝트 생성 전 루틴

1. 가상환경 생성
2. 가상환경 활성화
3. 쟝고 설치
4. 의존성 파일 생성 (패키지 설치시마다 진행)

 

• Django 프로젝트 생성 전 루틴 + git 을 사용할 경우

1. 가상환경 생성
2. 가상환경 활성화
3. 쟝고 설치 → pip install django 또는 pip install -r requirements.txt
4. 의존성 파일 생성 (패키지 설치시마다 진행)
5. .gitignore 파일 생성 (첫 add 전) → gitignore.io 참고하기!
6. git 저장소 생성 (git init 등)
7. 쟝고 프로젝트 생성 → django-admin startproject firstpjt .

쟝고 서버 실행 → python manage.py runserver

 

• 가상환경을 사용하는 이유

의존성 관리 → 라이브러리 및 패키지를 각 프로젝트마다 독립적으로 사용 가능

팀 프로젝트 협업 → 모든 팀원이 동일한 환경과 의존성 위에서 작업하여 버전 충돌을 방지

 

• 디자인 패턴

소프트웨어 설계에서 발생하는 문제를 해결하기 위한 일반적인 해결책!

= 공통적인 문제를 해결하는 데 쓰이는 형식화된 관행 (애플리케이션의 구조는 이렇게 구성하자!)

 

Ex) MVC 디자인 패턴 (Model View Controller)

→ 애플리케이션을 구조화하는 대표적인 패턴, 어떤 프레임워크를 쓰든 이렇게 디자인 하자는 약속

(데이터 & 사용자 인터페이스 & 비즈니스 로직을 분리)

 

Ex2) MTV 디자인 패턴 (Model Template View)

→ 위랑 똑같은 건데, 쟝고에서 이름만 바꾼 것!

Django에서 애플리케이션을 구조화하는 패턴

즉, MVC 패턴과 동일하나 단순히 명칭만 다르게 한 것.

( View → Template , Controller → View )

 

• 프로젝트와 앱

프로젝트 안에 여러 앱이 있는데, 보통 기능 별로 앱을 만든다.

마치 모듈처럼 기능을 하나하나 앱에 분담시키는 것.

 

• 앱을 사용하기 위한 순서

1. 앱 생성 (앱 이름은 복수형으로 지정하는 것을 권장함) → python manage.py startapp articles(앱 이름)
2. 앱 등록 (반드시 앱을 생성한 후에 등록해야 함. 등록 후 생성은 불가능) → settings.py 안에서 입력하면 된다. (보통 맨 위에 쓴다)

INSTALLED_APPS = [
    'articles',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

 

• 프로젝트 구조

settings.py → 프로젝트의 모든 설정을 관리

urls.py → 요청 들어오는 url에 따라 이에 해당하는 적절한 view를 연결

manage.py → 프로젝트와 다양한 방법으로 상호작용 하는 커맨드라인 유틸리티 (수정은 안함)

 

• 앱 구조

admin.py → 관리자용 페리지 설정

model.py → DB와 관련된 Model을 정의. MTV 패턴의 M

view.py → HTTP 요청을 처리하고 해당 요청에 대한 응답을 반환. MTV 패턴의 V

 

• 요청과 응답

1. URLs → http 주소로 요청이 왔을 때 views 모듈의 view 함수를 호출 앱 파일에서 views 모듈을 가져오기!! url 경로는 반드시 ‘/’ (slash)로 끝나야 한다!
2. View → 특정 경로에 있는 template과 request 객체를 결합해 응답 객체를 반환하는 함수를 정의 모든 view 함수는 첫번째 인자로 request 요청 객체를 필수적으로 받음 매개변수 이름이 request가 아니어도 작동하지만 그렇게 작성하지 않음!
3. Template articles 앱 폴더 안에 templates 폴더 생성 templates 폴더 안에 articles 폴더 생성 articles 폴더 안에 템플릿 파일 생성 폴더명은 반드시 templates 여야 하며 개발자가 직접 생성해야 함

 

• Django에서 template을 인식하는 경로 규칙

app 폴더 / templates / articles / index.html

app 폴더 / templates / example.html

(빨간색 지점까지는 Django가 기본 경로로 인식하기 때문에 view 함수에서 template 경로 작성 시 이 지점 이후의 경로를 작성한다!)

 

• 데이터 흐름에 따른 코드 작성 순서!

URLs → View → Template

URLs ⇒ path(’articles/’, views.index),

View ⇒ def index(request): return render(request, ‘articles/index.html’)

Template ⇒ articles/templates/articles/index.html

 

• render 함수

주어진 템블릿을 주어진 컨텍스트 데이터와 결합하고 렌더링 된 텍스트와 함께 HttpResponse 응답 객체를 반환하는 함수

render ( request, template_name, context )

request - 응답을 생성하는 데 사용되는 요청 객체

template_name - 템플릿 이름의 경로

context - 템블릿에서 사용할 데이터 (딕셔너리 타입으로 작성)

 

• Django 의 규칙

1. urls.py 에서 각 url 경로는 반드시 ‘/’ 로 끝남

2. views.py 에서 모든 view 함수는 첫번째 인자로 요청 객체를 받는다.

• 매개변수 이름은 반드시 request로 지정

3. Django는 정해진 경로에 있는 template 파일만 읽어올 수 있음

• app폴더/templates/ 이후