Pattern del repository: come strutturare i repository con le tabelle nidificate?

0

Sto lavorando su un'API e mi sembra sempre di imbattermi in questo dibattito sui pensieri. Quando si progetta la struttura del codice che interagisce con il database (repository, provider di dati ecc.) Come si strutturano i repository in base a relazioni gerarchiche?

Ad esempio, ho un'app con articoli e questi elementi hanno immagini. Creo un repository con le operazioni CRUD per entrambe le immagini e gli elementi o ne faccio due?

Di solito mi chiedo "bene, come faccio a modificare i dati?" e di solito ha senso fare un repository per ragioni di business. Aggiungerò sempre un'immagine in relazione a un oggetto. Tuttavia, se voglio avere qualcosa come un'interfaccia utente di amministratore che lo supporta, tutto va bene, poiché all'improvviso quelle tabelle sono ora quasi modificabili come se fossero le loro stesse entità. La relazione è ancora valida, ma vorrei fare qualcosa come Ottenere tutte le immagini o rimuovere questa immagine perché è offensiva.

L'obiettivo è provare e rendere la struttura del codice più sensata ed essere la più utilizzabile.

    
posta Ashtonian 10.05.2016 - 06:08
fonte

0 risposte

Leggi altre domande sui tag