I am developing a small ERP software. I'm wondering how to design entities as well as where to join them.
I'm just gonna start with an example, that makes it way easier.
Say I'm modelling a maintenance contract.
1-n purchasing prices
1-n selling prices
So I could go ahead in my domain layer, where I keep all the models and model a Contract class simply with its fields and a list of Machines.
A machine with a list of its fields and list of contacts, appointments and prices.
If I go with this approach, which certainly makes sense, what do I do when loading these classes from the database? If I write a method that simply loads a full contract from the database, I'm loading so much extra information that I might not need. Maybe I only need to display the head data from the contract.
If I load it only partially, I have to #1 write several methods to load the contracts from SQL, several queries. And #2 I always need to make sure that the right amount of properties are loaded, so its a lot of extra programming effort and room for mistakes.
What I am doing right now, is keeping a lot of the entities separate if they could logically stand on their own. (I'd go with the upper approach for example in an Order model since neither items nor an order really makes sense standalone)
Since I'm doing c# and MVVM I essentially have a Contract ViewModel, where I then have a list of Machine ViewModels and in there lists of Contact ViewModels etc.
This makes some sense to me, as I can freely mix entities together the way they need to be "viewed". The exact point of a viewmodel i think.
However, the class/method where I build those Contract ViewModels gets rather complicated and big. With a lot of lists, dictionaries grouping contacts by foreign keys etc. Making sure the models are in sync with the viewmodels.
And I'm not sure if I'm not misusing c# for the joining of entities when "thats SQLs job".
I am not used to seeing an architecture like this, so I'm wondering if I'm missing something?