Django는 강력한 웹 애플리케이션 프레임워크로서 최근 몇 년간 점점 더 많은 Python 개발자들이 Django에 투자하고 있지만, 또한 Django 콘텐츠의 수많은 문제로 인해 누구나 쉽게 접할 수 있습니다. 처음 Django에 들어가면 그들은 항상 약간 "약간 압도당하는" 느낌을 받고 어디서부터 시작해야 할지 모릅니다. 또는 처음 이해한 후에도 현재 접근 방식이 우아한지, 프로젝트를 구성하는 방법, 코드를 보다 재사용 가능하게 만드는 방법을 여전히 확신할 수 없습니다.
좋은 프로젝트 구조는 전투의 절반입니다.
기본적으로 Django에서 생성된 프로젝트 구조는 대략 다음과 같습니다.
프로젝트의 응용 프로그램 수가 계속 증가함에 따라 로컬 루트 디렉터리의 패키지도 계속 증가합니다. 파일의 수가 많아질수록 유지 관리가 점점 어려워지기 때문에 전체 프로젝트에 대한 명확한 계획을 세우고 각 파일을 합리적으로 배치해야 합니다.
프로젝트 규모가 작고 다양한 방법으로 애플리케이션을 재사용할 계획이 없다면 다음 방법을 고려해 보세요.
venv 폴더에는 프로젝트의 virtualenv 환경이 저장되며 필요하지 않습니다. 다른 곳에 배치하세요.
데이터베이스 앱은 모델을 저장하고 명령과 템플릿에 사용되는 일부 사용자 정의 필터를 관리하는 데 특별히 사용됩니다. 프로젝트 루트 디렉터리에 저장됩니다.
문서와 로그는 각각 프로젝트 관련 문서와 런타임 중에 생성된 로그 파일을 저장합니다.
static은 css/js/img/font 등과 같은 정적 파일을 저장합니다.
utils는 도구 기능, 프로젝트에 사용되는 클래스, 로거 등과 같은 일부 공통 모듈을 저장합니다.
템플릿은 템플릿 파일을 저장합니다. 여러 템플릿에서 상속된 템플릿은 루트 디렉터리에 배치되고 유지 관리가 쉽도록 기본과 같은 이름으로 명명됩니다.
웹 디렉토리는 모든 애플리케이션을 저장합니다. 애플리케이션이 많은 경우 계획을 위해 더 많은 패키지로 나눌 수 있습니다.
Model 모듈 부분에서는 주로 데이터를 클래스에 매핑하는 작업을 담당합니다. 일반적인 상황에서는 각 테이블에 해당하는 클래스가 별도의 파일에 배치되고 해당 클래스가 배치됩니다. models/__init__.py 클래스는 순서대로 임포트되기 때문에 다른 곳에서 사용할 때는 from Database.models import xxxx를 통해 임포트할 수 있습니다. 예를 들어, 여기에서 내 프로젝트의 이름은 Cherry이고, 모든 클래스는 CherryLeaks.CherryVulns 등입니다. 이 클래스가 데이터를 나타낸다는 것을 알면 코드 검토 및 작성 과정에서 한눈에 알 수 있습니다.
반복 작업을 피하기 위해 모델에 별도의 관리자를 추가하고 해당 방법을 구현하는 것이 좋습니다.
또한 실제 상황에 따라 선택할 수 있는 몇 가지 제안이 있습니다.
외래 키와 같은 유형을 사용하는 것은 권장되지 않습니다.
각 테이블에 is_deleted,created_time,update_time 필드를 추가하세요
잘 만드세요 use of indexes
대부분의 비즈니스 로직은 View 부분에 배치되어야 하며, 이 부분이 핵심이 되어야 합니다. 또한 유사한 기능을 가진 모든 뷰를 동일한 파일에 배치하는 것이 좋습니다. 향후 유지 관리 및 개발을 용이하게 하려면 이 파일을 "controller" 또는 "view"라는 패키지에 배치해야 합니다. 예를 들어 프로젝트 관련 라우팅 처리는 모두 Controller/project.py에 배치됩니다.
ListView, TemplateView 등과 같은 Django의 내장 View 클래스 중 일부를 사용하는 것을 선호합니다. View를 직접 구현해야 하는 경우 클래스 기반 보기를 사용하여 향후 유지 관리를 용이하게 하기 위해 다양한 요청 방법을 다양한 방법으로 캡슐화하는 것이 좋습니다. .
템플릿 파일의 경우 가장 좋은 방법은 다양한 페이지와 기능을 다양한 템플릿 파일로 잘라서 애플리케이션 이름으로 폴더에 저장하는 것입니다. 그러면 나중에 각 애플리케이션에서 해당 템플릿을 빠르게 검색할 수 있습니다. 해당 템플릿 파일.
또한, 템플릿 상속 기능을 사용하는 것이 좋습니다. 모든 페이지는 상위 템플릿에서 상속되며, 페이지 확장을 위해 다양한 블록이 사용되며, 하위 템플릿의 경우 각 위치의 블록 이름이 정의됩니다. 덮다. . 사이드바, 스크립트, 헤더, main_content, page_title, page_description 등과 같이 각 블록에 대해 대중적이고 짧은 이름을 사용하는 것이 좋습니다.
댓글 상자와 같은 일반적인 기능의 경우 별도의 파일에 저장하고 필요한 경우 {% include 'filename.tpl.html' %}을 통해 로드하는 것을 고려할 수 있습니다. 확장 및 포함 명령어를 동시에 사용해야 하는 경우 해당 명령어를 블록에서 사용해야 합니다. 그렇지 않으면 유효하지 않습니다. 다음 예는 유효하지 않습니다.
은 다음과 같이 사용해야 합니다.
Python 언어의 유연성으로 인해 코드를 작성할 때 특정 메소드의 매개변수 유형이나 반환 유형을 잊어버릴 때가 있습니다. 이 경우 다른 사람이 개발하고 유지할 수 있도록 docstring을 사용하여 각 메서드에 대한 명확한 정보 주석을 제공해야 합니다. 이 링크를 참조하세요. PyCharm을 사용하는 경우 자동 완성 독스트링을 작성할 수 있습니다.
우리 메서드는 호출자에게 여러 값을 반환하거나 JSON을 통해 프런트 엔드로 반환해야 하는 경우가 많습니다. 데이터가 무작위로 반환되면 개발 혼란이 발생할 수 있으며, 결국 우리는 메소드가 무엇을 반환하는지 알 수 없습니다.
더 나은 접근 방식은 반환 형식에 동의하는 것입니다. 호출자에게 반환하려면 간단히 튜플을 반환하고 독스트링에 각 값의 의미를 쓰세요. 결과를 반환하는 것 외에도 데이터 처리 중에 문제나 예외가 발생했는지 여부를 나타내기 위해 오류를 반환해야 하는 경우도 있습니다. 일반적으로 사용 가능한 방법은 여러 가지가 있습니다.
raise를 통해 예외 발생
err, result = func()와 같은 여러 반환 값을 통해 반환
instance = Class(와 같은 클래스의 속성을 통해 반환 ) ; err =instance.error_message
이 세 가지 방법은 모두 장단점이 있으며, 어떤 방법을 사용하든 프로젝트 전반에 걸쳐 일관되어야 하며 프로젝트의 실제 상황에 따라 선택해야 합니다. 가능한 한 많이 섞지 마세요.
프론트 엔드로 반환되는 JSON의 경우 조금 더 복잡해야 하며 최소 2~3개의 필드가 반환되어야 합니다.
code는 상태 코드입니다. 이 통화로 반환되며 실제 상황에 따라 합의될 수 있습니다. 메시지는 개발자가 디버깅하고 사용자에게 알림을 제공하는 데 사용할 수 있는 이해하기 쉬운 상태 코드 메시지입니다. data는 실제 반환된 데이터 정보입니다. 대부분의 경우 이 필드는 실제 상황에 따라 다시 합의해야 합니다.
우아하고 심플한 라우팅으로 프로젝트 품질을 보장하고 유지관리 비용을 절감합니다.
Django는 비즈니스의 다양한 요구를 충족할 수 있는 강력한 라우팅 시스템과 라우팅 알고리즘을 갖추고 있으며, 각 라우팅 구성 파일은 URL PATH에서 함수/클래스로의 매핑입니다. 프레임워크나 기타 제한 사항의 적용을 받지 않고 모든 것을 직접 설정할 수 있습니다. Django의 요청 라우팅 전략에 대한 문서의 이 섹션을 참조할 수 있습니다.
경로를 구성할 때 나중에 쉽게 사용할 수 있도록 일부 변수를 꺾쇠 괄호로 묶을 수 있습니다. 일부 "경로 변환기"는 str, int, slug, uuid, path와 같은 변수 유형을 지정하기 위해 꺾쇠 괄호 안에 사용될 수 있습니다. 전체 URL 라우팅 파일은 다음과 같습니다.
또한 re_path를 통해 경로에서 일반 일치를 설정할 수도 있습니다.
때때로 기본 경로를 추가할 수도 있습니다. 예를 들면 다음과 같습니다. /blog/에 접속하면 기본 페이지를 반환하고, /blog/page
프로젝트가 계속 확장되고 사용되는 경로 수가 계속 증가할 것이므로 Django는 다양한 앱에서 경로를 쉽게 구성할 수 있도록 경로 포함 메커니즘을 제공합니다. 간단한 예를 살펴보겠습니다.
이 예에서는 Community/*를 요청하는 모든 경로가 구문 분석을 위해 aggregator.urls로 전달됩니다. 마찬가지로 contact/*에 대한 모든 요청도 다른 경로로 전달됩니다. 하나. 라우팅 모듈이 이를 처리합니다. 프로젝트에 애플리케이션이 많지 않지만 포함을 통해 라우팅을 관리하려면 다음 방법을 사용할 수 있습니다.
일반적으로 각 Django 프로젝트는 여러 앱으로 구성됩니다. 모든 앱 경로가 URLCONF_ROOT에 배치되면 이 파일은 시간이 지남에 따라 유지 관리가 점점 더 어려워지고 매우 혼란스러워질 것입니다. 동일한 이름의 경로가 다른 앱에서 사용되어 충돌이 발생할 수 있습니다. 이러한 문제를 해결하려면 "경로 포함"과 "네임스페이스"를 사용하면 됩니다. 특히 재사용이 가능한 앱을 유지 관리하는 경우 경로의 고유성을 보장하려면 네임스페이스가 특히 중요합니다.
일반적으로 애플리케이션 네임스페이스와 인스턴스 네임스페이스의 두 가지 유형의 네임스페이스가 있습니다. 예를 들어 admin:index는 admin 네임스페이스의 인덱스 경로를 나타냅니다. 이 부분에 대한 자세한 내용은 공식 문서
를 참조하세요.애플리케이션 네임스페이스는 애플리케이션 수준의 네임스페이스를 의미하며 일반적으로 다음과 같이 구성됩니다.
인스턴스 네임스페이스는 앱에서 자주 사용되는 인스턴스 수준의 네임스페이스를 의미합니다. 인스턴스화의 경우 각 인스턴스를 구별하기 위해 Instance Namespace를 도입해야 합니다. 공식 문서의 예를 살펴보겠습니다.
두 개의 경로 Author-Polls와Publisher-Polls가 실제로 동일한 경로를 포함하지만 서로 다른 네임스페이스를 지정하는 것을 볼 수 있습니다. , 즉 현재 액세스 중인 개체의 네임스페이스입니다. 예를 들어 방문자와 관리자는 모두 polls:index가 가리키는 페이지에 액세스하지만 네임스페이스가 다르기 때문에 완전히 다른 결과를 얻게 됩니다.
위 내용은 Django 개발 방법이란?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
