Supponiamo di avere un concettuale Ledger popolato con Line Items . Supponiamo che Line Items siano memorizzati in qualche tipo di memoria persistente. Il libro mastro viene mostrato all'utente che può aggiungere / rimuovere Line Items o aggiornare le variabili all'interno di un particolare Line Item , come prezzo / quantità / descrizione.
Per gestire questo, per esempio, potrei scrivere una classe singola usando il livello del repository, chiamarla qualcosa come LineItemRepository , e avere funzioni come loadLineItems() , addLineItem() , removeLineItem() , changeQuantityX() , ecc.
Per fare le sue operazioni la classe dovrà essere a conoscenza di cose come
-
ledger_idper caricare tutti gli elementi pubblicitari relativi a quell'id o per aggiungere un elemento pubblicitario al libro mastro -
line_item.idper rimuovere / aggiornare unLine Item
Sembracheconl'aiutodiunaclasseController,questosaràtuttociòdicuihobisognoperattivareeventideldominioaziendalecome"Aggiungi nuovo elemento pubblicitario", "Aggiorna prezzo elemento pubblicitario", "Elimina elemento pubblicitario", ecc. Posso anche fare cose come "Trova la somma di tutti gli elementi pubblicitari con Descrizione" x "all'interno di Ledger Y".
Il mio repository può essere essenzialmente un Ledger
Domanda
1) Va bene mantenere il concetto di Ledger e Line Item Repository in una singola classe concettualmente rispetto a SRP e SOC? Se sì, come posso chiamare questa classe? ItemRepositoryLedger ?
2) Quando ho bisogno, perché potrei aver bisogno, o ho sempre bisogno di un oggetto Ledger separato (rappresentazione in memoria di ciò che è nel database, con le funzionalità aziendali) da Repository (assegnato con effettiva funzionalità di recupero e archiviazione del database, presumibilmente inconsapevole delle funzionalità aziendali)?
Penso che potrei usare questa classe in-memory Ledger per cose come
- Carica tutti gli elementi pubblicitari contemporaneamente e non toccare il database per un po 'finché non ho davvero bisogno di
- Aggiungi, modifica l'aggiornamento elimina gli elementi pubblicitari nella% in memoria
Legderper quanto mi serve prima di svuotarli tutti nel database. Mentre lo faccio, il database potrebbe non essere sincronizzato se è aggiornato da qualcun altro (anche se nel mio caso specifico tali casi saranno rari ...) - Esegui varie operazioni matematiche sugli elementi pubblicitari senza toccare o sottolineare il database con ogni nuovo modo in cui voglio sommare le cose, ad esempio.
Ma i problemi che vedo è che tale Ledger conterrà temporaneamente le informazioni duplicate di ciò che è nel database. Questo mi sembra "CATTIVO". Ma forse no. Cosa succede se voglio caricare i record e quindi fare diverse aggiunte di prezzi diversi senza colpire il database per ogni nuovo?
Obiettivo
Il mio obiettivo per questa domanda è ottenere una comprensione più chiara dei concetti di Repository e della struttura in memoria come Ledger nell'universo MVC.
La comprensione corrente è che il repository viene utilizzato solo per memorizzare / recuperare dati e non è utilizzato, ad esempio, per calcolare il prezzo totale di LineItems. Una classe Ledger lo farebbe, dopo aver prima utilizzato Repository per caricare Line Items in memoria.
Ma potrei anche usare il repository per sommare gli elementi pubblicitari per me usando SQL. Quindi sono un po 'confuso qui ...
Altri pensieri
Posso fare un ulteriore passo avanti e chiedere .. Ho bisogno di un oggetto in memoria Line Item per rappresentare quello nel database? Credo che avrò bisogno di qualche variabile oggetto per memorizzare i dati ricevuti dal database, per poterlo mostrare nel livello View. Senza di esso, devo chiamare il repository dal mio View.
Quindi probabilmente ho bisogno di qualche struttura / oggetto / collezione di variabili per rappresentare Line Item , finché non è pronto per essere visualizzato nella Vista.
L'oggetto Ledger dovrebbe seguire la stessa logica?
Ledger è essenzialmente un oggetto Controller , un gestore di Repository in questo caso e non un'entità separata solo per il dominio?