wake-up-neo.net

Django: "Projekte" gegen "Apps"

Ich habe ein ziemlich komplexes "Produkt", das ich mit Django erstellen möchte. Ich werde es vermeiden, in diesem Zusammenhang die Begriffe "Projekt" und "Anwendung" zu verwenden, da mir deren spezifische Bedeutung in Django nicht klar ist.

Projekte können viele Apps haben. Apps können für viele Projekte freigegeben werden. Fein.

Ich erfinde den Blog oder das Forum nicht neu. Ich sehe keinen Teil meines Produkts in irgendeinem Zusammenhang wiederverwendbar. Intuitiv würde ich diese eine "Anwendung" nennen. Mache ich dann meine ganze Arbeit in einem einzigen "App" -Ordner?

Wenn ja ... in Bezug auf Djangos project.app Namespace ist es meine Neigung, myproduct.myproduct Zu verwenden, aber das ist natürlich nicht erlaubt (aber die Anwendung, die ich ' m building ist mein Projekt und mein Projekt ist eine Anwendung!). Ich bin daher der Meinung, dass ich Django vielleicht durch Erstellen einer App pro "signifikantem" Modell ansprechen soll, aber ich weiß nicht, wo ich die Grenzen in meinem Schema ziehen soll, um es in Apps aufzuteilen - Ich habe viele Modelle mit relativ komplexen Beziehungen.

Ich hoffe, es gibt eine gemeinsame Lösung für diese ...

pythondjangonamespacesproject-organization
193
Dolph

Was soll Sie daran hindern, myproduct.myproduct zu verwenden? Was Sie brauchen, um das ungefähr zu erreichen, besteht darin, dies zu tun:

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

und so weiter. Wäre es hilfreich, wenn ich sagen würde, dass views.py nicht views.py heißen muss? Vorausgesetzt, Sie können im Pfad python=) eine Funktion (normalerweise package.package.views.function_name) benennen, die behandelt wird ist nur python Pakete.

Nun, wie soll man das machen? Oder eher, wie könnte ich das machen? Nun, wenn Sie ein signifikantes Stück wiederverwendbarer Funktionalität erstellen, wie beispielsweise einen Markup-Editor, dann erstellen Sie eine "Top-Level-App", die möglicherweise widgets.py, fields.py, context_processors.py etc - alle Dinge, die Sie importieren möchten.

Wenn Sie so etwas wie ein Blog in einem Format erstellen können, das über mehrere Installationen hinweg ziemlich allgemein ist, können Sie es in einer App mit einer eigenen Vorlage, einem statischen Inhaltsordner usw. zusammenfassen und eine Instanz eines Django Projekt, um den Inhalt dieser App zu verwenden.

Es gibt keine festen Regeln, die besagen, dass Sie dies tun müssen, aber es ist eines der Ziele des Frameworks. Die Tatsache, dass Sie alles, einschließlich Vorlagen, von einer gemeinsamen Basis aus einbinden können, bedeutet, dass Ihr Blog problemlos in jedes andere Setup passt, indem Sie sich einfach um seinen eigenen Teil kümmern.

Um jedoch Ihr eigentliches Anliegen anzugehen, können Sie mit dem Projektordner der obersten Ebene nicht arbeiten. Genau das können Apps und Sie können es tun, wenn Sie es wirklich wollen. Ich neige jedoch aus mehreren Gründen nicht dazu:

  • Djangos Standard-Setup macht das nicht.
  • Oft möchte ich eine Haupt-App erstellen, also erstelle ich eine, normalerweise website. Zu einem späteren Zeitpunkt möchte ich jedoch möglicherweise die ursprüngliche Funktionalität nur für diese Site entwickeln. Um es entfernbar zu machen (unabhängig davon, ob ich es jemals tue oder nicht), neige ich dazu, ein separates Verzeichnis zu erstellen. Dies bedeutet auch, dass ich diese Funktionalität einfach löschen kann, indem ich das Paket aus der Konfiguration lösche und den Ordner entferne, anstatt die richtigen URLs aus einem globalen urls.py-Ordner zu löschen.
  • Sehr oft, selbst wenn ich etwas unabhängig machen will, muss es irgendwo leben, während ich mich darum kümmere/es unabhängig mache. Grundsätzlich der obige Fall, aber für Sachen, die ich vorhabe, generisch zu machen.
  • Mein oberster Ordner enthält oft ein paar andere Dinge, einschließlich, aber nicht beschränkt auf, wsgi-Skripte, sql-Skripte usw.
  • Djangos Verwaltungserweiterungen stützen sich auf Unterverzeichnisse. Daher ist es sinnvoll, Pakete entsprechend zu benennen.

Kurz gesagt, der Grund, warum es eine Konvention gibt, ist der gleiche wie bei jeder anderen Konvention - es hilft, wenn andere an Ihrem Projekt arbeiten. Wenn ich fields.py sehe, erwarte ich sofort, dass der darin enthaltene Code das Feld von Django unterordnet. Wenn ich inputtypes.py sehe, ist mir möglicherweise nicht klar, was das bedeutet, ohne es anzusehen.

56
user257111

Sobald Sie die Verwendung von startproject und startapp abgeschlossen haben, hindert nichts Sie daran, ein "Projekt" und eine "App" im selben Python) - Paket zu kombinieren Projekt ist eigentlich nichts anderes als ein settings Modul, und eine App ist tatsächlich nichts anderes als ein models Modul - alles andere ist optional.

Für kleine Websites ist es durchaus sinnvoll, Folgendes zu haben:

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

Versuchen Sie die Frage zu beantworten: "Was macht meine Bewerbung?". Wenn Sie nicht in einem Satz antworten können, können Sie ihn möglicherweise in mehrere Apps mit übersichtlicherer Logik aufteilen.

Ich habe diesen Gedanken irgendwann gelesen, nachdem ich angefangen habe, mit Django zu arbeiten, und ich stelle mir diese Frage ziemlich oft und es hilft mir.

Ihre Apps müssen nicht wiederverwendbar sein, sie können voneinander abhängen, aber sie sollten eine Sache tun.

69
Ski

Ich habe die folgenden Blog-Posts für Django Anwendungen und Projekte als sehr nützlich empfunden:

Grundsätzlich haben Sie mit Django) viel Freiheit bei der Organisation des Quellcodes Ihres Produkts.

15
JooMing

Wenn ja ... in Bezug auf Djangos project.app-Namespace, neige ich dazu, myproduct.myproduct zu verwenden, aber das ist natürlich nicht erlaubt

Es ist nichts dergleichen nicht erlaubt. Es ist dein Projekt, niemand schränkt dich ein. Es ist ratsam, einen vernünftigen Namen beizubehalten.

Ich sehe keinen Teil meines Produkts in irgendeinem Zusammenhang wiederverwendbar. Intuitiv würde ich diese eine "Anwendung" nennen. Mache ich dann meine ganze Arbeit in einem einzigen "App" -Ordner?

In einem allgemeinen Django Projekt gibt es viele Apps (Contrib-Apps), die wirklich in jedem Projekt verwendet werden.

Nehmen wir an, Ihr Projekt erledigt nur eine Aufgabe und hat nur eine einzige App (ich nenne sie main, da sich das Projekt darum dreht und kaum steckbar ist). Auch in diesem Projekt werden im Allgemeinen noch einige andere Apps verwendet.

Wenn Sie nun sagen, dass Ihr Projekt nur die eine App verwendet (INSTALLED_APPS='myproduct'), Sollten Sie einige Punkte in Betracht ziehen, wie project das Projekt als project.app Definiert :

  • Es gibt viele andere Dinge, die der Code außer der App in einem Projekt handhabt (statische Basisdateien, Basisvorlagen, Einstellungen ... d. H. Die Basis).
  • Im allgemeinen project.app-Ansatz definiert Django automatisch das SQL-Schema aus Modellen.
  • Ihr Projekt wäre mit dem herkömmlichen Ansatz viel einfacher zu erstellen.
  • Sie können nach Belieben verschiedene Namen für URLs, Ansichten und andere Dateien definieren, aber ich sehe keine Notwendigkeit.
  • Möglicherweise müssen Sie in Zukunft einige Anwendungen hinzufügen, die mit den konventionellen Django -Projekten sehr einfach sind. Andernfalls wird es möglicherweise genauso oder schwieriger und langwieriger.

Was den größten Teil der in der App geleisteten Arbeit betrifft, denke ich, dass dies bei den meisten Django -Projekten der Fall ist.

8
crodjer

Hier Django creators weist selbst auf diesen Unterschied hin . Ich denke, dass das Nachdenken über Apps, wie sie sein müssen wiederverwendbar in anderen Projekten ist gut. Auch eine gute Denkweise über Apps in Django) bieten moderne Webanwendungen.

Stellen Sie sich vor, Sie erstellen eine große dynamische Web-App, die auf JavaScript basiert.

Sie können dann in Django App mit dem Namen "FrontEnd" <- in dieser App werden Inhalte angezeigt.

Dann erstellen Sie einige Backend-Apps. ZB App mit dem Namen "Kommentare", die Benutzerkommentare speichern. Und "Kommentare" App wird nichts selbst anzeigen. Es wird nur eine API für AJAX Anforderungen Ihrer dynamisch [~ # ~] js [~ # ~] sein website.

Auf diese Weise können Sie Ihre "Kommentare" -App immer wieder verwenden. Sie können es Open Source machen, ohne die Quelle des gesamten Projekts zu öffnen. Und Sie halten sauber Logik Ihres Projekts.

1
Qback