Strategia applicativa di Django


14

Ho lavorato per un po 'a un progetto Django che è cresciuto un po' di recente. Ho riflettuto un po 'su quale strategia utilizzare per semplificare la gestione. Una cosa su cui vorrei ottenere qualche input sarebbe se dovessi dividere la mia applicazione in diverse applicazioni più piccole. Ciò renderebbe i miei file di visualizzazione e modello più piccoli e separerebbe alcune delle preoccupazioni.

Una cosa che mi preoccupa di questo è che nelle mie applicazioni avrei diversi metodi di supporto che verranno utilizzati in tutte le applicazioni. Inoltre, alcuni modelli dovranno essere condivisi / utilizzati tra le applicazioni. Questo avrebbe senso? Questo non va bene con la separazione delle preoccupazioni che speravo di ottenere dividendo la mia app in diverse app più piccole. Quale sarebbe un buon approccio per condividere metodi di supporto, modelli ecc. Tra le applicazioni?

Risposte:


11

Se il tuo progetto sta diventando grande, pensa alle app come moduli riutilizzabili. Puoi separare la funzionalità condivisa tra le tue app nella sua app.

Vedi le discussioni di seguito per ulteriori riflessioni sulla questione:


Cosa succede se un'app deve aggiungere alcune voci di menu alla navigazione del progetto? stackoverflow.com/questions/23405610
utapyngo

2

Mi piace creare base/un'app senza visualizzazioni e senza momenti per le cose condivise.

Un problema che può verificarsi quando si hanno modelli distribuiti su più app è l'importazione circolare. Questo può essere evitato usando le stringhe per fare riferimento ad altri modelli ( foo = ForeignKey("someapp.Foo")anziché foo = ForeignKey(someapp.models.Foo)). Django ti consente di utilizzare stringhe come questa in più punti.

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.