Progettazione / layout FS per grandi progetti Django [chiuso]

Question

Qual è il modo migliore per impaginare un grande progetto Django?I tutorial forniscono semplici istruzioni per l'impostazione di app, modelli e visualizzazioni, ma ci sono meno informazioni su come suddividere app e progetti, quanta condivisione è consentita/necessaria tra le app in un progetto tipico (ovviamente ciò dipende in gran parte da progetto) e come/dove conservare i modelli generali.

Qualcuno ha esempi, suggerimenti e spiegazioni sul perché un certo layout di progetto è migliore di un altro?Sono particolarmente interessato all'incorporazione di un gran numero di test unitari (2-5 volte la dimensione della base di codice effettiva) e all'esternalizzazione/modelli di stringhe.

Answer 1

Le linee guida principali sono simili a qualsiasi altro progetto di codice di grandi dimensioni.Le app dovrebbero affrontare un’unica responsabilità chiaramente definita.Il nome "applicazione" è un termine improprio;Le app Django dovrebbero essere pensate più come componenti riutilizzabili che possono essere collegati insieme per creare una vera applicazione.I test per ciascuna app devono essere contenuti all'interno dell'app stessa.Le app dovrebbero essere disaccoppiate il più possibile l'una dall'altra, ma chiaramente ci saranno delle dipendenze, quindi l'obiettivo dovrebbe essere quello di mantenere il grafico delle dipendenze il più semplice e corretto possibile.

Preferisco mantenere tutti i modelli per un progetto in un'unica directory dei modelli a livello di progetto, con una sottodirectory per ogni app (l'utilizzo di una sottodirectory dei modelli per ogni app è una convenzione molto forte in Django, poiché evita collisioni dei nomi dei modelli tra le app) .Il motivo per cui esiste una singola directory di modelli a livello di progetto è che i modelli, gli alberi di ereditarietà dei modelli e i nomi dei blocchi possono essere piuttosto specifici del progetto, quindi è difficile fornire modelli di app "predefiniti" che possano essere collegati a qualsiasi progetto.Ci sono stati alcuni tentativi di stabilire convenzioni di denominazione standard per i modelli di base dell'intero sito e i blocchi che definiscono, ma non ho ancora visto emergere uno standard (il modo in cui fanno le cose su Pinax è probabilmente la cosa più vicina a uno standard che abbiamo).

Per quanto riguarda "esternalizzazione delle stringhe", se intendi i18n e l10n, Django ha un forte supporto per questo e per i luoghi standard in cui inserisce i file .po: controlla il documenti.

Answer 2

Ho trovato il layout di Zachary piuttosto utileBlog di Zachary Voase » Convenzioni del progetto Django, rivisitate.

Answer 3

Questa pagina fa un buon lavoro nel rispondere ad alcune delle mie domande: http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/

Nello specifico:

1. Per definire tag o filtri di template personalizzati, è necessario creare una sottodirectory nella directory dell'applicazione denominata templatetags e deve contenere un file denominato __init__.py in modo che possa essere importato come modulo Python.
2. Per definire unit test che verranno automaticamente rilevati dal framework di test di Django, inseriscili in un modulo chiamato tests (che può essere un file chiamato tests.py o una directory chiamata tests).Il framework di testing troverà anche eventuali doctest in quel modulo, ma il posto preferito per questi sono, ovviamente, le docstring delle classi o funzioni che sono progettate per testare.
3. Per fornire un SQL personalizzato che verrà eseguito immediatamente dopo l'installazione dell'applicazione, crea una sottodirectory denominata sql all'interno della directory dell'applicazione;i nomi dei file dovrebbero essere gli stessi dei nomi dei modelli sulle cui tabelle opereranno;ad esempio, se hai un'app denominata weblog contenente un modello denominato Entry, il file sql/entry.sql all'interno della directory dell'app può essere utilizzato per modificare o inserire dati nella tabella delle voci non appena è stata creata.

La nota su tests.py e tests (la directory) vale anche per i modelli, il che aiuta a risolvere il problema di avere molti test (o modelli) per un file.

Mi piacerebbe ancora vedere alcuni esempi/suggerimenti per la scomposizione di app/progetti e grandi siti Django che funzionino bene.

Answer 4

IL Progetto Pinax è costruito attorno all'idea di piccole app riutilizzabili, che possono essere facilmente riunite in un progetto.Hanno utilizzato il progetto Nuvola 27 come progetto dimostrativo.

Il progetto Django a cui sto lavorando (chiamato Basie.È precedente alla versione 0.1, quindi ancora nessun collegamento.) sta cercando di seguire il modello Pinax e finora sta funzionando abbastanza bene.

Answer 5

Il mio layout attuale deriva dal desiderio di avere una versione di prova dei miei siti.Ciò significa avere due progetti per ogni sito, poiché necessitano di configurazioni diverse, e mi costringe a spostare tutte le applicazioni fuori dai progetti.

Ho creato due cartelle:$APP_ROOT/devel e $APP_ROOT/prod.Questi contengono tutte le app.Utilizzando il controllo del codice sorgente (nel mio caso git) ho le app in devel alla revisione HEAD, mentre le app in prod sono bloccate sul tag PROD.I modelli hanno anche una propria cartella con lo stesso layout delle app.

Ora posso eseguire tutto lo sviluppo nella cartella devel-apps e nella cartella template corrispondente.Quando ho qualcosa di cui sono soddisfatto, taggo quella revisione e aggiorno il prodotto.

Answer 6

mi piace molto Randall Degge' post su questo argomento.Tralascia informazioni su come unire insieme i file delle impostazioni, ma avrò un post su cui potrò collegarmi, ma per ora chiunque può controllare il mio repository dove includo alcune indicazioni nel file readme.