Suppose I have a conceptual
Ledger that is populated with
Line Items. Assume that
Line Items themselves are stored in some type of persistent storage. The ledger is shown to the user who can add/remove
Line Items, or update variables inside a particular
Line Item, such as price/quantity/description.
To handle this, for example, I could write a single class using Repository layer, call it something like
LineItemRepository, and have it have functions like
To do its operations the class will need to be aware of things like
ledger_idto load all the line items pertaining to that id, or to add a line item to the ledger
line_item.idto remove/update a
It looks like with an aid of a
Controller class, this will be all I need to trigger business domain events like "Add new Line Item", "Update Line Item Price", "Delete Line Item", etc. I can also do things like "Find Sum of all Line Items with Description 'x' inside Ledger Y".
My Repository can essentially be a
1) Is it okay to keep the concept of
Line Item Repository in a single class conceptually with respect to SRP and SOC? If so how do I call this class?
2) When do I need, why might I need, or do I ever need a separate
Ledger object (in-memory representation of what is in the database, tasked with business functionality) from the
Repository (tasked with actual database retrieval and storage functionality, presumably unaware of business functionality) ?
I think that I could use such in-memory
Ledger class for things like
- Load all line items at once into it and then not touch the database for a while until I really need to
- Add, edit update delete Line Items in the in-memory
Legderas much as I need to before flushing them all into the database. While I do so the database may become out of sync if it is updated by someone else (although in my specific case such cases will be rare...)
- Perform various many math operations on the Line Items without touching or stressing the database with each new way I want to sum things for example.
But the problems I see is that such
Ledger will temporarily contain duplicate information of what is in the database. That strikes me as "BAD". But maybe not. What if I want to load records and then do several various item pricing additions without hitting the database for each new one?
My goal for this question is to get a clearer understanding of here concepts of
Repository, and in-memory structure such as
Ledger fit in the MVC universe.
Current understanding is that Repository is only used to store/retrieve data and is not used to, for example, compute total price of LineItems. A
Ledger class would do that, after first using Repository to load the
Line Items into memory.
But then I could also use Repository to sum the line items for me using SQL. So I am a bit confused here...
I can take it a step further and ask .. Do I need an in memory
Line Item object to represent the one in the database? I guess I will need some object variable to store the data received from the database, to be able to show it in the View layer. Without it, I have to call repository from my View.
Thus I probably need some structure/object/collection of variables to represent
Line Item, until it is ready to be displayed in the View.
Ledger object follow the same logic?
Ledger essentially a
Controller object, a manager of
Repository in this case and not a separate domain-only entity?