Django: "progetti" vs "app"


202

Ho un "prodotto" abbastanza complesso che mi sto preparando a costruire usando Django. Eviterò di usare i termini "progetto" e "applicazione" in questo contesto, perché non sono chiaro sul loro significato specifico in Django.

I progetti possono avere molte app. Le app possono essere condivise tra molti progetti. Belle.

Non sto reinventando il blog o il forum - non vedo nessuna parte del mio prodotto riutilizzabile in nessun contesto. Intuitivamente, chiamerei questa "applicazione". Devo quindi svolgere tutto il mio lavoro in un'unica cartella "app"?

Se è così ... in termini di project.appspazio dei nomi di Django , la mia inclinazione è quella di usare myproduct.myproduct, ma ovviamente questo non è permesso (ma l'applicazione che sto costruendo è il mio progetto e il mio progetto è un'applicazione!). Sono quindi indotto a credere che forse dovrei avvicinarmi a Django costruendo un'app per modello "significativo", ma non so dove tracciare i confini del mio schema per separarla in app: ho molto di modelli con relazioni relativamente complesse.

Spero che ci sia una soluzione comune a questo ...


1
I documenti spiegano la differenza tra "applicazione" e "progetto" qui: docs.djangoproject.com/en/dev/ref/applications/…
guettli

Risposte:


56

Cosa ti impedisce di usare myproduct.myproduct? Ciò di cui hai bisogno per raggiungere questo obiettivo consiste essenzialmente nel fare questo:

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

e così via. Aiuterebbe se dicessi views.pyche non deve essere chiamato views.py? A condizione che tu possa nominare, sul percorso python, una funzione (di solito package.package.views.function_name) che verrà gestita. Semplice come quella. Tutta questa roba "progetto" / "app" è solo pacchetti python.

Ora, come dovresti farlo? O meglio, come potrei farlo? Bene, se crei una significativa funzionalità riutilizzabile, come ad esempio un editor di markup, è quando crei una "app di livello superiore" che potrebbe contenerewidgets.py , fields.py, context_processors.pyecc - tutte le cose che si potrebbe desiderare di importazione.

Allo stesso modo, se riesci a creare qualcosa di simile a un blog in un formato piuttosto generico tra le installazioni, puoi racchiuderlo in un'app, con il suo modello, cartella di contenuti statici ecc. E configurare un'istanza di un progetto django per usarlo contenuto dell'app.

Non ci sono regole rigide e veloci che dicono che devi farlo, ma è uno degli obiettivi del framework. Il fatto che tutto, inclusi i modelli, ti consenta di includere da una base comune significa che il tuo blog dovrebbe adattarsi perfettamente a qualsiasi altra configurazione, semplicemente occupandosi della propria parte.

Tuttavia, per rispondere alle tue attuali preoccupazioni, sì, nulla dice che non puoi lavorare con la cartella di progetto di livello superiore. Questo è ciò che fanno le app e puoi farlo se lo desideri davvero. Tendo a non, tuttavia, per diversi motivi:

  • L'impostazione predefinita di Django non lo fa.
  • Spesso, voglio creare un'app principale, quindi ne creo una, di solito chiamata website . Tuttavia, in un secondo momento potrei voler sviluppare funzionalità originali solo per questo sito. Al fine di renderlo rimovibile (anche se non lo faccio mai) tendo a creare una directory separata. Questo significa anche che posso eliminare tale funzionalità semplicemente scollegando quel pacchetto dalla configurazione e rimuovendo la cartella, piuttosto che una complessa cancellazione degli URL corretti da una cartella globale urls.py.
  • Molto spesso, anche quando voglio rendere qualcosa indipendente, ha bisogno di un posto in cui vivere mentre lo prendo cura / lo faccio indipendente. Fondamentalmente il caso sopra, ma per cose che intendo fare generico.
  • La mia cartella di livello superiore contiene spesso alcune altre cose, inclusi ma non limitati a script wsgi, script sql ecc.
  • Le estensioni di gestione di django si basano su sottodirectory. Quindi ha senso nominare i pacchetti in modo appropriato.

In breve, la ragione per cui esiste una convenzione è la stessa di qualsiasi altra convenzione: aiuta quando si tratta di altri che lavorano con il tuo progetto. Se vedo, fields.pymi aspetto immediatamente che il codice in esso sia una sottoclasse del campo di Django, mentre se vedo inputtypes.pypotrei non essere così chiaro su cosa significhi senza guardarlo.


24
+1 ... "Cosa ti impedisce di usare myproduct.myproduct?" - Il comando "startapp" di Django in realtà ti blocca, credo, come una convenzione. Mi piacciono le convenzioni, soprattutto nel contesto di uno sforzo di squadra, ma preferisco capire la logica dietro di loro :)
Dolph,

@Dolph ah, vero? Non l'ho usato dalla prima volta che l'ho usato perché ho il mio comando per la creazione di un progetto che prima crea modelli, quindi genera automaticamente roba CRUD per questi modelli. Tuttavia, le convenzioni sì sono buone. Seguo le convenzioni di django se non altro perché in gran parte hanno senso.

1
Aggiungerò che l'uso dello stesso nome per un progetto e un'app al suo interno causano anche problemi manage.py, impedendogli di importare correttamente le impostazioni del progetto. Questo è successo a me e l'ho risolto riformattando l'app per l'effetto di myproduct_app.
BHSPitMonkey

89

Una volta che ti sei laureato usando startprojecte startapp, non c'è nulla che ti impedisca di combinare un "progetto" e "app" nello stesso pacchetto Python. Un progetto non è altro che un settingsmodulo e un'app non è altro che un modelsmodulo: tutto il resto è facoltativo.

Per i siti di piccole dimensioni, è del tutto ragionevole avere qualcosa di simile:

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

18
Riepilogo +1: il progetto ha settings.py, l'app ha models.py. Hanno la stessa struttura di livello. Pensavo che il progetto fosse di un livello superiore all'app, suppongo di aver sbagliato
Philip007

2
@claymation, cosa dovrebbe essere incluso nelle impostazioni (come app) per consentire 'python manage.py makemigrations' o 'python manage.py migrate' per vedere il file 'models.py' nella directory 'my product'?
mlwn del

1
@mlwn Mi rendo conto di essere in ritardo a rispondere a questa domanda, ma mi trovo in una situazione simile e ho cercato molte risposte. Per rispondere alla tua domanda, tutto ciò che devi fare è includere il tuo progetto INSTALLED_APPSnell'elenco. Ecco un esempio: stackoverflow.com/a/59739912/399435
Karthic Raghupathi

@KarthicRaghupathi, grazie .. :) bello vedere i commenti a cui viene data risposta dopo quattro anni .. evviva
mlwn

69

Prova a rispondere alla domanda: "Cosa fa la mia domanda?". Se non riesci a rispondere in una sola frase, forse puoi dividerlo in diverse app con una logica più pulita.

Ho letto questo pensiero da qualche parte subito dopo aver iniziato a lavorare con Django e trovo che mi pongo questa domanda abbastanza spesso e mi aiuta.

Le tue app non devono essere riutilizzabili, possono dipendere l'una dall'altra, ma dovrebbero fare una cosa.


8
Sto ancora lottando un po 'quando si tratta di presentare la mia app. Sento che la mia applicazione principale è un po 'pesante, ma allo stesso tempo, non sarei in grado di trasformarla in qualcosa di simile a qualcosa di vagamente accoppiato. Sono incline a pensare che non sarebbe davvero un miglioramento separare le mie principali entità principali, se dipendono ancora fortemente l'una dall'altra, e non c'è bisogno di riutilizzare o generalizzare all'orizzonte. Mi sto orientando verso "non refactoring prematuramente" come interpretazione di "non ottimizzare prematuramente"
acjay,


8

Se è così ... in termini di spazio dei nomi project.app di Django, la mia inclinazione è di usemyproduct.myproduct, ma ovviamente questo non è permesso

Non c'è niente come non permesso. È il tuo progetto, nessuno ti sta limitando. Si consiglia di mantenere un nome ragionevole.

Non vedo alcuna parte del mio prodotto riutilizzabile in nessun contesto. Intuitivamente, chiamerei questa "applicazione". Devo quindi svolgere tutto il mio lavoro in un'unica cartella "app"?

In un progetto django generale ci sono molte app (app contrib) che vengono utilizzate davvero in ogni progetto.

Diciamo che il tuo progetto ha una sola attività e ha una sola app (lo chiamo mainmentre il progetto ruota attorno ad esso ed è difficilmente collegabile). Anche questo progetto usa ancora alcune altre app in generale.

Ora, se dici che il tuo progetto sta usando solo un'app ( INSTALLED_APPS='myproduct') quindi a cosa serve projectdefinire il progetto come project.app, penso che dovresti considerare alcuni punti:

  • Ci sono molte altre cose che il codice diverso dall'app in un progetto gestisce (file statici di base, modelli di base, impostazioni .... ovvero fornisce la base).
  • Nell'approccio generale project.app django definisce automaticamente lo schema sql dai modelli.
  • Il tuo progetto sarebbe molto più semplice da costruire con l'approccio convenzionale.
  • Puoi definire nomi diversi per URL, visualizzazioni e altri file come desideri, ma non ne vedo la necessità.
  • Potrebbe essere necessario aggiungere alcune applicazioni in futuro, cosa che sarebbe molto semplice con i progetti di django convenzionali che altrimenti potrebbero diventare ugualmente o più difficili e noiosi da fare.

Per quanto riguarda la maggior parte del lavoro svolto nell'app, penso che sia il caso della maggior parte dei progetti di Django.


1
+1, esp per la mainconvention - per me ha molto senso un progetto originale come questo. Ho intenzione di aggiungere app "riutilizzabili" in un secondo momento, ma in questo momento è ben al di fuori della mia attenzione.
Dolph,

2

Qui i creatori di Django sottolineano questa differenza . Penso che pensare alle app in quanto debbano essere riutilizzabili in altri progetti è positivo . Anche un buon modo di pensare alle app di Django fornisce applicazioni web moderne.

Immagina di creare grandi app Web dinamiche basate su JavaScript .

È quindi possibile creare in App django denominata ad esempio "FrontEnd" <- in questa app verrà visualizzato il contenuto.

Quindi crei alcune app back-end. Ad esempio l'app denominata "Commenti" che memorizzerà i commenti degli utenti. E l'app "Commenti" non mostrerà nulla da sola. Sarà solo un'API per le richieste AJAX del tuo sito Web JS dinamico .

In questo modo puoi sempre riutilizzare l'app "Commenti". Puoi renderlo open source senza aprire il sorgente dell'intero progetto. E mantieni pulita la logica del tuo progetto.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.