Utilizzo di una classe per un elemento di raccolta, con metodi per accedere ad altre raccolte

0

Spero di ottenere un controllo di integrità nel mio pensiero progettuale.

Sto lavorando con un piccolo team su un sito web basato su un database MongoDB. Ci sono diverse raccolte nel DB, ad esempio una che rappresenta persone e una che rappresenta i sondaggi. Le persone votano nei sondaggi e i loro voti sono registrati in una matrice votes in ciascun sondaggio, come un documento con il numero identificativo della persona e il voto che hanno espresso (ad esempio, sì o no). Le persone hanno informazioni sulla posizione e altre informazioni sul profilo.

Tutto il codice è in Python. Allo scopo di estrarre dati dal DB per un'API e per la visualizzazione web, sto pensando di creare una classe Person e una classe Poll. Ognuno di questi avrebbe metodi per ottenere dati dalle altre raccolte.

Ad esempio, una persona avrebbe Person.get_polls() o Person.get_votes() che andrebbero nell'altra raccolta e recupereranno tutti i sondaggi a cui una persona ha partecipato e troveranno i voti che hanno inserito in ciascuno di essi. Allo stesso modo, un sondaggio avrebbe Poll.get_persons() che restituirebbe l'elenco di dati personali dalla raccolta Persone per tutti coloro che avevano votato in quel sondaggio.

Ogni volta che uno sviluppatore vuole che una caratteristica ottenga sondaggi o persone, passerà attraverso questo sistema di classe, piuttosto che accedere al database direttamente con le query di pymongo, perché le query verrebbero incorporate nelle classi.

È un approccio standard? Ciò promuove la flessibilità perché possiamo cambiare facilmente il nostro database semplicemente cambiando le implementazioni del metodo una volta? O riduce la flessibilità perché lega tutto all'utilizzo di quelle classi?

    
posta Hatshepsut 05.10.2016 - 19:52
fonte

2 risposte

1

Fondamentalmente, stai dicendo che vuoi un'interfaccia più orientata agli oggetti al database sottostante. Per RDBMS, questo software è chiamato Object Relational Mapper ed è estremamente complesso, ma necessario (?) Per sistemi di grandi dimensioni. Per MongoDB in Python, c'è MongoEngine. Come con qualsiasi strumento, dovresti valutarlo e determinare se è adatto alle tue esigenze. Se la tua applicazione è piccola, è possibile che una libreria di terze parti sia eccessiva e puoi scrivere una semplice raccolta di funzioni e classi di utilità.

Soprattutto, dovresti discutere anche con gli altri membri della tua squadra. Forse sono perfettamente felici a scrivere query JSON.

    
risposta data 06.10.2016 - 05:16
fonte
-2

Each of these [collections] would have methods to get data from the other collections.

No! Questo è un accoppiamento di dipendenze inappropriato.

Bene, ovviamente il codice cliente deve essere in grado di usare un'altra classe. Innanzitutto, una raccolta (Persona) è solo una raccolta (ripetere se necessario). Per fare qualcosa con esso ci dovrebbe essere una classe "funzionalità di polling". Questa classe chiama i getter delle varie collezioni, perché conosce da solo quali raccolte e parti di esso ha bisogno per svolgere le sue funzioni di polling / voto.

Avrai metodi "get_persons"? Certo, ma prendendo argomenti filtranti in modo che l'API sia appropriatamente generica e non presupponga lo scopo specifico della chiamata.

Persons have information about location and other profile info.

Certamente. Ma ... Le classi di persone non dovrebbero assumere alcuna particolare funzionalità o uso per tali informazioni. Le persone classificate sapranno cosa significa "uguale" o come confrontarsi con un altro oggetto Persone in modo che una collezione di Persone possa ordinare se stessa. Potrebbe emettere dati in un formato particolare. Ma non dovrebbe sapere quale sia l'aggregazione personalizzata con altre classi per "funzionalità di polling"

Every time a developer wants a feature to get polls or persons, they'd go through this class system, rather than accessing the database directly

Sì.

In primo luogo, il livello aziendale è più strettamente collegato alla fonte dei dati. Un sacco di accesso al database w / in una classe è un accoppiamento più lento rispetto alla diffusione su molte classi.

In secondo luogo, i client possono assumere uno stato valido; ecco a cosa servono i costruttori. E le raccolte possono mantenere uno stato valido come non consentire duplicati, controllare la mutabilità, ecc.

In terzo luogo, il client, "funzionalità di polling" e la logica di business in generale, dovrebbero funzionare indipendentemente dall'interfaccia utente e dall'archivio dati.

    
risposta data 06.10.2016 - 15:08
fonte

Leggi altre domande sui tag