Ho un progetto che ho scritto in PHP/symfony che utilizza 45 tabelle. Sono in procinto di portarlo su Python/Django.Come decidere come suddividere il tuo progetto Django in app
C'è una convinzione che ho sostenuto per anni che dovresti suddividere i tuoi progetti in un mucchio di piccoli file piuttosto che in pochi file enormi. Da quello che capisco, non è una cosa strana da credere. In Rails e symfony, c'è una convenzione di un modello per file. In Django, tuttavia, sembra che la maggior parte degli sviluppatori abbia inserito tutti i modelli di ciascuna app in un unico file.
Questo ha senso per me se le tue app sono abbastanza piccole. Non ha senso per me per le app di grandi dimensioni, tuttavia, e quello che ho è almeno un'app di grandi dimensioni.
Dei 45 tavoli utilizzati dal mio progetto, 35 sono strettamente correlati. Ho uno script che importa i dati dai file CSV. Per ogni riga in ogni file CSV, ho salvato 50-80 pezzi di dati in 30-35 diversi tavoli in un colpo solo.
Forse sto solo pensando a questo nel modo sbagliato ma mi sembrerebbe incredibilmente strano dividere il mio progetto in 6 o 7 diverse app quando quasi tutte le mie tabelle sono inestricabilmente collegate. Quando tocco un tavolo, tocco tutti e 35 i tavoli. Le delinzioni dovrebbero essere arbitrarie. Quale sarebbe il punto di ciò?
Per favore perdonami se vengo offeso perché di solito sono prevenuto. Non ho questo problema in symfony e non lo farei su Rails. (Ho scelto Django a causa delle funzionalità GIS di GeoDjango e Python.)
- In un mondo perfetto, avrei un modello per file.
- Se provo ad avere un modello per file, ottengo problemi di riferimento circolare.
- Potrei evitare i problemi di riferimento circolare inserendo tutti i miei modelli in un file, ma questo mi sembra sbagliato.
- Potrei evitare di mettere tutti i miei modelli nello stesso file dividendoli in app separate, ma per finire con app sufficientemente piccole, dovrei interrompere il mio progetto in modi arbitrari (e quindi inutili).
Cosa devo fare?