장고 :“프로젝트”대“앱”

장고 :“프로젝트”대“앱”

---

Django를 사용하여 빌드를 준비하는 상당히 복잡한 "제품"이 있습니다. Django의 특정 의미에 대해 명확하지 않기 때문에이 맥락에서 "프로젝트"와 "응용 프로그램"이라는 용어를 사용하지 마십시오.

프로젝트에는 많은 앱이있을 수 있습니다. 많은 프로젝트에서 앱을 공유 할 수 있습니다. 좋아.

블로그 나 포럼을 다시 만들지 않습니다. 어떤 맥락에서도 제품의 일부를 재사용 할 수 없습니다. 직관적으로, 나는 이것을 "애플리케이션"이라고 부릅니다. 그런 다음 하나의 "app"폴더에서 모든 작업을 수행합니까?

그렇다면 ... Django의 project.app네임 스페이스 측면 에서 내 성향은을 사용하는 myproduct.myproduct것이지만 물론 이것은 허용되지 않습니다 (그러나 내가 만들고있는 응용 프로그램은 내 프로젝트이고 내 프로젝트는 응용 프로그램입니다!). 따라서 "중요한"모델 당 하나의 앱을 작성하여 Django에 접근해야한다고 생각하지만, 스키마에서 앱으로 분리하기 위해 스키마의 경계를 어디로 그릴 지 모르겠습니다. 비교적 복잡한 관계의 모델

나는 이것에 대한 일반적인 해결책이 있기를 바라고있다 ...

---

사용을 중지하는 것은 무엇입니까 myproduct.myproduct? 이를 달성하기 위해 필요한 것은 대략 다음과 같이 구성됩니다.

django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py

등등. 내가 views.py불릴 필요가 없다고 말하면 도움이 views.py되겠습니까? 파이썬 경로에서 처리 할 함수 (일반적으로 package.package.views.function_name)의 이름을 지정할 수 있다면. 그렇게 간단합니다. 이 "프로젝트"/ "앱"은 모두 파이썬 패키지입니다.

이제 어떻게해야합니까? 아니면 어떻게 할 수 있습니까? 재사용 가능한 기능의 상당 부분을 작성하는 경우 뭐, 같은 당신이 "최고 수준의 응용 프로그램을"만들 때 포함 할 수있는 사용자들은, 마크 업 편집기 말 widgets.py, fields.py, context_processors.py모든 것을 가져올 수있다 - 등.

마찬가지로 설치 과정에서 매우 일반적인 형식으로 블로그와 같은 것을 만들 수있는 경우 자체 템플릿, 정적 콘텐츠 폴더 등을 사용하여 앱에서 블로그를 마무리하고 장고 프로젝트 인스턴스를 구성하여 사용할 수 있습니다 앱의 콘텐츠.

이 작업을 수행해야한다는 단단하고 빠른 규칙은 없지만 프레임 워크의 목표 중 하나입니다. 템플릿에 포함 된 모든 항목을 사용하면 공통 기반을 포함 할 수 있다는 사실만으로 블로그 자체 구성 요소를 살펴보면 블로그가 다른 설정에 꼭 맞아야합니다.

그러나 실제 관심사를 해결하기 위해 최상위 프로젝트 폴더로 작업 할 수 있다고 말하는 것은 없습니다. 그것이 바로 앱이하는 일 이며, 원한다면 할 수 있습니다. 그러나 여러 가지 이유로 나는하지 않는 경향이 있습니다.

• 장고의 기본 설정은 그렇게하지 않습니다.
• 종종 메인 앱을 만들고 싶어서 보통이라고하는 앱을 만듭니다 website. 그러나 나중에이 사이트를 위해 독창적 인 기능을 개발하고 싶을 수도 있습니다. 이동식인지 확인하기 위해 (내가 아니든간에) 별도의 디렉토리를 만드는 경향이 있습니다. 이것은 전역 urls.py 폴더에서 올바른 URL을 복잡하게 삭제하는 대신 구성에서 해당 패키지를 연결 해제하고 폴더를 제거하여 해당 기능을 삭제할 수 있음을 의미합니다.
• 아주 자주, 내가 독립적 인 것을 만들고 싶을 때조차도 그것을 돌보고 / 독립적으로 만드는 동안 살 곳이 필요합니다. 기본적으로 위의 경우이지만 물건을 위해 일반화하려고합니다.
• 내 최상위 폴더에는 종종 wsgi 스크립트, sql 스크립트 등을 포함하여 몇 가지 다른 것들이 포함됩니다.
• django의 관리 확장 기능 은 하위 디렉토리에 의존합니다. 따라서 패키지 이름을 적절하게 지정하는 것이 좋습니다.

간단히 말해, 컨벤션이있는 이유는 다른 컨벤션과 동일합니다. 프로젝트를 수행하는 다른 사람들에게 도움이 될 때 도움이됩니다. 내가 볼 경우 fields.pydjango의 필드를 서브 클래스로 묶는 코드를 즉시 기대하지만, 그것을 보지 inputtypes.py않으면 그 의미가 무엇인지 명확하지 않을 수 있습니다.

---

사용 졸업 후 startproject와 startapp같은 파이썬 패키지에 "프로젝트"와 "응용 프로그램을"결합에서 당신을 막을 아무것도 없다. 프로젝트는 settings모듈에 지나지 않으며, 앱은 models모듈에 지나지 않습니다 . 다른 모든 것은 선택 사항입니다.

소규모 사이트의 경우 다음과 같은 것이 좋습니다.

site/
    models.py
    settings.py
    tests.py
    urls.py
    views.py

---

"응용 프로그램은 무엇을합니까?"라는 질문에 대답하십시오. 한 문장으로 대답 할 수 없다면, 논리를 깔끔하게 정리하여 여러 앱으로 나눌 수 있습니다.

나는 django와 함께 일하기 시작한 직후 어딘가 에서이 생각을 읽었으며 나는이 질문을 자주 자주 묻는 것이 나에게 도움이된다는 것을 알게되었습니다.

앱은 재사용 할 필요가 없으며 서로 의존 할 수 있지만 한 가지만해야합니다.

---

다음 블로그 게시물은 django 응용 프로그램 및 프로젝트에 매우 유용합니다.

• http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/
• http://web.archive.org/web/20080302205555/www.pointy-stick.com/blog/2007/11/09/django-tip-developing-without-projects/

In principle, you have a lot of freedom with django for organizing the source code of your product.

---

If so... in terms of Django's project.app namespace, my inclination is to usemyproduct.myproduct, but of course this isn't allowed

There is nothing like not allowed. Its your project, no one is restricting you. It is advisable to keep a reasonable name.

I don't see any portion of my product being reusable in any context. Intuitively, I would call this one "application." Do I then do all my work in a single "app" folder?

In a general django project there are many apps (contrib apps) which are used really in every project.

Let us say that your project does only one task and has only a single app (I name it main as thethe project revolves around it and is hardly pluggable). This project too still uses some other apps generally.

Now if you say that your project is using just the one app (INSTALLED_APPS='myproduct') so what is use of project defining the project as project.app, I think you should consider some points:

• There are many other things that the code other than the app in a project handles (base static files, base templates, settings....i.e. provides the base).
• In the general project.app approach django automatically defines sql schema from models.
• Your project would be much easier to be built with the conventional approach.
• You may define some different names for urls, views and other files as you wish, but I don't see the need.
• You might need to add some applications in future which would be real easy with the conventional django projects which otherwise it may become equally or more difficult and tedious to do.

As far as most of the work being done in the app is concerned, I think that is the case with most of django projects.

---

Here Django creators points out that difference themselves. I think that thinking about Apps as they have to be reusable in other projects is good. Also a good way of thinking about Apps in Django provide modern web applications.

Imagine that you are creating big dynamic web app basing on JavaScript.

You can create then in django App named e.g "FrontEnd" <-- in thins app you will display content.

Then you create some backend Apps. E.g App named "Comments" that will store user comments. And "Comments" App will not display anything itself. It will be just API for AJAX requests of your dynamic JS website.

In this way you can always reuse your "Comments" app. You can make it open source without opening source of whole project. And you keep clean logic of your project.

참고URL : https://stackoverflow.com/questions/4879036/django-projects-vs-apps