Separazione dei modelli di Django per SOA

Question

Separazione dei modelli di Django per SOA

#1 da (2 voti)

4

Innanzitutto, l'obiettivo di questo esercizio è creare un SOA con Django.

Sto cercando di capire quali sarebbero le implicazioni se decidessi di separare e isolare i modelli in app, fornire un'API REST per accedere a tali app e quindi creare altre app che utilizzano fondamentalmente l'API REST per ottenere dati ed eseguire operazioni su i modelli (DB).

Ho letto la documentazione e ho giocato con Django per un po '(non troppo a lungo), ma, per quanto posso dire, le uniche caratteristiche importanti di Django che vorrei essere in anticipo sono la possibilità di utilizzare viste e forme generiche. Dato che non ho molta esperienza con Django mi piacerebbe avere più informazioni prima di saltarci sopra.

Quali altre funzioni veramente utili di Django dovrei perdere?
C'è un modo per superare questo problema senza esporre i modelli ad altre app?

web-development rest soa django

posta AnilM3 07.02.2015 - 16:10

fonte

1 risposta

Leggi altre domande sui tag web-development rest soa django

Quando si distribuisce il codice su un server di produzione, come vengono gestite le risorse del codice non sorgente come immagini e PDF? Effettuare una sequenza strettamente crescente unendo i numeri vicini usando il minor numero di mosse

score 2 · Accepted Answer

What other really useful Django features would I lose?

"Lose" è probabilmente il modo sbagliato di pensarci. Non usare mai e occupare spazio è probabilmente più preciso. Si potrebbe sostenere che Django è un quadro troppo grande per ciò che stai descrivendo. C'è qualche ragione particolare per cui devi usare Django? Un micro-quadro come Flask potrebbe adattarsi meglio ai requisiti, è leggero e non dovrebbe includere molto codice che non userete mai.

Is there a way to overcome this without exposing the models to other Apps?

Non esponi i modelli tramite HTTP, esponi le risorse. Alcune volte le risorse saranno le stesse del modello, ma altre volte non lo faranno. Alcuni framework web mappano i modelli alle risorse in modo da 1 a 1, ma in questi giorni è considerata una cattiva idea codificare in modo duro questa mappatura, poiché rende le tue app molto meno flessibili (il tuo modello potrebbe cambiare con l'aumentare dell'app ma non necessariamente vuoi che le tue risorse cambino)

Quindi pensa alle risorse e al tuo modello di dominio come due cose correlate ma separate.