Hello,
My business logic layer is using a domain model. The classes in the domain have intricate associations with each other and make lots of little calls to each other. This is fine for business logic on the server. On the UI, I use Data Transfer Objects to move data between UI/BLL. The DTOs map 1:1 with the domain objects, but they don't have the deep references graphs. Basically the only references between the DTOs are strict aggregations such as an Order and it's collection of OrderDetails ( NOT an Order and a reference to it's Customer object). So the OrderDTO class has a collection of OrderDetailDTOs. When sending a list of OrderDTOs to the gui, it seems very inefficient to load each one's orderdetails as well. Using lazy load is not an option, since the DTOs should not have any reference to any repositories, services or other querying mechanism. So it seems like either you populate the OrderDetails always, or violate the OrderDTO's interface and leave it's details empty in certain cases.
So, do you guys normally populate the child collections when returning a list of DTOs, or just use common sense and know that when it's a list the childredn won't be filled, but if it was obtained by itself for the purpose of editing it will have the children populated
Data Transfer Objects and Collections
curiousss
I would suggest that you slightly change your perspective from plain DTOs to messages. A DTO is just data, without any intent, whereas a message can contain both data and intent. It is much easier to process and respond to notifications when you know what the other side intended. For instance, instead of sending an OrderDTO with its orderlines to the server, and having it go through all the orderlines in order to understand that 2 orderlines were updated, one added, and 4 deleted, a message could pass all the information together. Further, consider that you can have multiple kinds of messages for different situations, no need to try to have a single DTO be good for everything.
I think that this move will simplify both the communication protocol and the code that handles it.
Best of luck.
FC-Shiro
Interesting...
What would a message look like Maybe a "EditOrder" message, with separate collections representing "modified", "deleted", "added" items Something like that
Thanks
IrishWolf
Udi, I appreciate your post (as always). I tried to find info on message-based data-transfer and ended up reading chapter 1 of "EJB Design Patterns" by Floyd Marinescu. This opened my eyes to a couple of concepts that I would like to get your views on as they pertain this topic, and .NET.
A big realization was, as you said, that I don't necessarily have to use a list of "OrderDTO" objects if the client only needs to display a read-only list of a sub-set of order-data fields. The book mentions using a simple JDO record-set to transport this tabular data. In .NET, this would be a DataTable. I've always tried to stay away from DataTables for this because 1. I thought they were not fully binary serializable (really heavy), and 2. the client needs to know the names and data-types of the columns which adds a clunky sort of coupling not to mention loss of intellisense. But now I know that the serialization is no longer an issue with .NET 2.0, so now I am reconsidering. To address the coupling issue, it's true that there are work-arounds such as using readonly static strings somewhere to publish the names of the columns in the DataTables so that client and server stay in synch, but even that seems kind of hacky and clumsy design. But on the other hand, not having to do all that DTO mapping and marshalling for a simple read-only list seems like a huge time-saver / LOC reducer, would perform better, and might actually increase agility overall. What do you think