Quando creare una nuova app (con startapp) in Django?
Ho cercato su google per questo, ma ho ancora problemi con ciò che Django definisce "app".
Devo creare una nuova app per ogni funzionalità in un sito, anche se utilizza i modelli del progetto principale?
Ragazzi, avete una buona regola generale su quando dividere una nuova app e quando mantenere la funzionalità insieme al "progetto principale" o ad altre app?
James Bennett ha un meraviglioso set di diapositive su come organizzare app riutilizzabili in Django.
Preferisco pensare alle applicazioni Django come a moduli o componenti riutilizzabili che come "applicazioni".
Questo mi aiuta a incapsulare e disaccoppiare alcune funzionalità l'una dall'altra, migliorando la riutilizzabilità nel caso in cui decido di condividere una particolare "app" con la comunità in generale e la manutenibilità.
Il mio approccio generale è mettere a punto funzionalità o set di funzionalità specifiche in "app" come se li stessi pubblicando. La parte difficile qui è capire quanto è grande ogni singolo bucket.
Un buon trucco che uso è immaginare come sarebbero state utilizzate le mie app se fossero state rilasciate pubblicamente. Questo spesso mi incoraggia a restringere i secchi e definire più chiaramente il suo "scopo".
Tendo a creare nuove applicazioni per ciascun insieme di modelli logicamente separati. per esempio.:
- Profili utente
- Messaggi del forum
- I post del blog
Ecco la presentazione aggiornata il 6 settembre 2008.
DjangoCon 2008: Apps riutilizzabili @ 7: 53
Diapositiva: Reusable_apps.pdf
Tratto dalla diapositiva
Dovrebbe essere la sua applicazione?
- È completamente estraneo alla messa a fuoco dell'app?
- È ortogonale a qualsiasi altra cosa stia facendo?
- Avrò bisogno di funzionalità simili su altri siti?
Se qualcuno di loro è "Sì"? Quindi è meglio romperlo in un applicazione separata.
La regola che seguo è che dovrebbe essere una nuova app se voglio riutilizzare la funzionalità in un progetto diverso.
Se ha bisogno di una profonda comprensione dei modelli del tuo progetto, probabilmente è più coeso a tenerlo con i modelli.
Una 'app' potrebbe essere molte cose diverse, tutto si riduce davvero al gusto. Ad esempio, diciamo che stai costruendo un blog. La tua app potrebbe essere l'intero blog oppure potresti avere un'app "admin", un'app "site" per tutte le visualizzazioni pubbliche, un'app "rss", un'app "services" in modo che gli sviluppatori possano interfacciarsi con il blog nella loro modi propri, ecc.
Personalmente, renderei il blog stesso l'app e estrapolare le funzionalità al suo interno. Il blog potrebbe quindi essere riutilizzato piuttosto facilmente in altri siti web.
La cosa bella di Django è che riconoscerà qualsiasi file models.py all'interno di qualsiasi livello dell'albero della directory come un file contenente i modelli Django. Quindi rompere la tua funzionalità in "subapp" più piccole all'interno di una "app" non renderà nulla di più difficile.
Le due migliori risposte a questa domanda che ho trovato sul Web sono:
- Il Riusable Apps Talk ( slide ) ( video ) è menzionato anche in altre risposte. Bennett, l'autore e contributore di Django, pubblica regolarmente app da usare per gli altri e ha un forte punto di vista verso molte piccole app.
- I consigli di Doordash per Django su scala che dà il consiglio opposto e dice che nel loro caso sono migrati a una singola app dopo aver iniziato con molte app separate. Hanno incontrato problemi con il grafico delle dipendenze della migrazione tra le app.
Entrambe le fonti concordano sul fatto che dovresti creare un'app separata nelle seguenti situazioni:
- Se hai intenzione di riutilizzare la tua app in un altro progetto Django (soprattutto se prevedi di pubblicarlo per il riutilizzo da parte di altri).
- Se l'app ha poche o nessuna dipendenza tra questa e un'altra app. Qui potresti essere in grado di immaginare un'app in esecuzione come proprio microservizio in futuro.