Ho appena creato un'applicazione per i flask e finora ho un router per il mio "Hello world!" modello.Struttura cartella/file comune nell'app Flask
Vorrei aggiungere un po '(molto) più funzionalità, ma mi chiedo come strutturare la directory dell'app.
Qual è il modo più comune di strutturare un'app Flask? Ad esempio, dovrei creare uno routes.py per tutti i miei percorsi? Dove vanno le cose SQLAlchemy? I modelli dovrebbero essere in models.py?
Si consiglia di controllare la pagina Applicazioni più grandi nella sezione Motivi dei documenti Flask: http://flask.pocoo.org/docs/patterns/packages/. Sembra essere il modello seguito dalla maggior parte delle persone quando la loro applicazione richiede un pacchetto anziché un modulo.
Credo che views.py sia quello che si chiama routes.py. Successivamente, i modelli andrebbero in models.py, i moduli andrebbero in forms.py, ecc.
Penso che il pallone sia un framework micro e ora devi decidere come creare file e cartelle.
Io uso questo modo:
questo è vicina struttura di Django
io suggerisco di vedere qualche progetto per darvi quello che volete
Si potrebbe ottenere ispirato ai modelli cookiecutter qui per avviare il vostro sviluppo di app
Un esempio di una directory FlaskApp:
yourapp/
/yourapp
/run.py
/config.py
/yourapp
/__init__.py
/views.py
/models.py
/static/
/main.css
/templates/
/base.html
/requirements.txt
/yourappenv
run.py - contiene il codice Python effettivo che importerà l'app e avvierà il server di sviluppo.
config.py - memorizza le configurazioni per la tua app.
__init__.py - inizializza l'applicazione creando un'istanza dell'app Flask.
views.py - qui è definito routes.
models.py - qui si definiscono i modelli per la propria applicazione.
static - contiene file statici, ad esempio CSS, Javascript, immagini
templates - questo è dove si memorizzano i modelli html, ad es.index.html, layout.html
requirements.txt - questo è dove si memorizzano i dipendenze dei pacchetti, è possibile utilizzare pip
yourappenv - l'ambiente virtuale per lo sviluppo
per' requirement.txt' e 'venv'. –
Direi che se si divide l'applicazione utilizzo delle divisioni piuttosto che la struttura funzionale. Io sostengo questo perché è più probabile lavorare su uno di questi componenti divisionali in qualsiasi momento.
Questo tipo di struttura si presta bene su marketplace o app SaaS in cui diversi gruppi di utenti utilizzano un diverso tipo di visualizzazioni. App per le API solo API Potrei usare la divisione funzionale.
Ecco alcuni esempi di Flask Blueprints. I progetti sono essenzialmente un consiglio documentato su come suddividere l'applicazione Flask per pezzi più gestibili. Ulteriori informazioni su questo: http://exploreflask.com/en/latest/blueprints.html
Ecco un esempio di divisione divisionale. Guarda come ciascuna caratteristica è raggruppata.
yourapp/
__init__.py
admin/
__init__.py
views.py
static/
templates/
home/
__init__.py
views.py
static/
templates/
control_panel/
__init__.py
views.py
static/
templates/
models.py
Ecco l'esempio funzionale>
yourapp/
__init__.py
static/
templates/
home/
control_panel/
admin/
views/
__init__.py
home.py
control_panel.py
admin.py
models.py
Non capisco che, perché abbiamo un solo file per tutti i modelli? Che dire della pratica 'una classe per file'? Cosa succede se alcuni modelli sono abbastanza grandi? Dovremmo spostare parte della logica in altri moduli? Eppure, se volessi che i miei modelli fossero in file separati, dovrei semplicemente creare un "modello" di modulo? Grazie! – lime
@lime, come strutturare il progetto quando ci sono più modelli ?, posso aiutarmi per favore. –
@lime Non sono un fan di "una classe per file". Trovo che percorsi di importazione ripetitivi e ripetitivi siano ingombranti. Si finisce anche con un sacco di importazioni extra per far sì che tutto sia separato, a meno che non si importi tutto in un '__init __. Py', che può essere difficile da mantenere. Detto questo, sei libero di strutturare il tuo progetto come preferisci. Stavo semplicemente offrendo una convenzione che molte persone seguono. – dirn