dove esattamente dovrebbe essere posizionata la logica di business di python in django

I have done a lot of searching but I am still not able to figure out where exactly should I place this Python file containing all the logic.

Ci sono un certo numero di opzioni, a seconda di quali sono i tuoi requisiti:

1. Aggiungi la logica ad es. il modello Image . Questa è un'opzione utile se è necessario memorizzare metadati per immagine nel database e ogni istanza di modello (ogni immagine) viene elaborata da sola.

2. Aggiungi la logica come una semplice classe Python Image , ad es. in un file chiamato image.py . Niente in Django ti impedisce di aggiungere una logica diversa da quella nei moduli views o models . Questa è una buona opzione se la logica dell'immagine è un componente centrale della tua app Django (ad esempio un'app di elaborazione delle immagini).

3. Crea un progetto Python separato che fornisce la logica, quindi chiamalo dalle tue visualizzazioni. Assicurati di installare questo progetto nell'ambiente Python dell'app Django. Questa opzione è valida se lo scopo della tua app Django è caricare e visualizzare immagini o mostrare i risultati dell'elaborazione dell'immagine in risposta diretta alla richiesta dell'utente, ma dove l'elaborazione dell'immagine può essere utilizzata anche da altri progetti.

4. Crea un'app separata che elabora le richieste in modo asincrono e viene eseguita separatamente dall'app Django. Questa opzione è utile se devi disaccoppiare l'elaborazione delle immagini dal ciclo di richiesta dell'app, elaborare un numero elevato di immagini o dove ogni calcolo impiega troppo tempo per risolverlo nel tempo di un ciclo di richiesta (diciamo al massimo tra 500ms e 1s) .

I feel it is intuitively not right since model should exclusively communicate with the back end.

Non c'è niente in Django che richieda un modello per comunicare con il back-end, o meglio il database. Penso che tu stia mescolando la semantica di ciò che Django considera tipicamente un modello (vale a dire, un'astrazione di una o più tabelle nel database), v.s. il termine modello come costrutto di progetto (ad esempio come nel Domain Driven Design).

Daniel Greenfeld, coautore di "Two Scoops of Django, raccomanda la logica di business dovrebbe essere nei modelli" quando possibile, o nelle forme se è necessario. "Per quanto riguarda il possibile duplicato di Bart, il django potrebbe essere simile a MVC ma non è MVC. Come spiegato qui nel django ufficiale documentazione faq. @adrita, penso che potrebbe essere necessario rivedere la documentazione ufficiale per aiutarti a capire meglio il concetto di modelli, viste e modelli.

Nel documento ufficiale di Django link , si dice:

Django has the concept of “views” to encapsulate the logic responsible for processing a user’s request and for returning the response. Find all you need to know about views via the links below:

Django consiglia di includere la logica all'interno delle viste.