Could you point me to a place where there is discussion on how best to transport data that is spread out over many tables. I have some ideas below working though ways to handle it, so if you don't have a link handy, just let me know if you think this approach
will work or if I should explore something different.
Let's say I had to create a form that had customers. And we had lots of codes for each customer (but only stored the code key, not the description). And we had a number of child tables (invoices, invoice detail, parts, etc.) that had to be shown on the same
form using either page frames or expander type controls.
So I can get the data from the SQL source using the entity framework - so that part is covered. I just need to know how best to package the data to go down to the client via a service.
I am guessing I would include :
The properties for the fields in the main customer record
A list<> of each detail table (but if there are multiple invoices, would each invoice entry in the invoices list include a details list<> element, with the details list including a parts list<> element, etc.
And in separate calls, get all the various code categories and details so I can populate the various controls that allow the user to pick the right code (say a list of territories, a list of customer types, a list of market types, etc.) as these would be read
only and only used to allow the user to see the appropriate description instead of some code that means nothing to them.
When the user then saves the data and I send it all back (using the same structure I would assume), then I would just update the EF with the values that changed and tell it to save. I am guessing that the mapper just copies the data values from one object to
another, without trying to determine if they have changed or not. If so, I may try to create a subclass that has an option to compare and only update the value if the values don't match (so we don't do needless updates/validations.)
Jun 14, 2013 at 12:08 PM
When using services for something like this, you basically have two different options: 1) retrieve items in small junks and 2) retrieve it all at once. Which path you choose depends on your usage scenario. If you have a form that shows a customer and then
you allow opening an invoices tab showing invoices, which the user may or may not navigate to, then perhaps it is better to retrieve the invoices only on demand. On the other hand, if you pretty much know users always want to see a customer's invoices, it
is probably better to have a single call that returns customers and their invoices as a hierarchy.
Note: I would probably always keep thing that are logically "one item" (like an invoice and its line items) together in a single call. Really, the fact that they are split into multiple tables are an artifact of relational database mechanics and do
not as such reflect the real entity (an invoice without line items doesn't make sense to anyone, except for us developers :-)).