Hi everybody,
In my opinion, how to resolve the scenario that Weera is mentioning will depend mostly of how and what you need to pass between the Domain and Data layers.
For example, if your ContactModel has a collection of ContactAdressModels, a simple approach could be to convert each element one by one manually by doing something like this:
/* WARNING - The following is psedo-code. May need to be changed in order to work */ // Supposing GetContactsByObj returns a list of Contacts IEnumerable<Contact> rawItems = this.entityRepository.GetContactsByObj(factor); List<ContactModels> items = new List<string>(); foreach(var rawItem in rawItems) { var item = new ContactModel() { ContactID = rawItem.ContactID, FirstName = rawItem.FirstName, LastName = rawItem.LastName }; foreach(var rawAddress in rawItem.ContactAddresses) { var address = new ContactAddressModel() { AddressID = rawAddress.AddressID, Address = rawAddress.Address, City = rawAddress.City, ContactModel = item } item.ContactAddressModels.Add(address); } items.Add(item); }
However, this is only one approach and might not be suitable for all scenarios (for example, it might cause problems when having a many-to-many relationship between models.)
On the other hand, it's not required for the data model and the domain model to have exactly the same properties. In the case of Silk, there are domain models that contain only the information of the data model that is required. An example of this are the Vehicle (data) and VehicleModel (domain) classes. The Vehicle data model contains two collections, one of FillupEntries and other of Reminders. However, these collections don't exist in the VehicleModel.
Instead of transforming the Reminders collection to a collection of ReminderSummaryModels and storing it in the VehicleModel, Silk simply ignores it; and when those are required, Silk obtains the corresponding Reminders for that Vehicle directly from the repository. This can be seen, for example, in the GetVehicleListForUser and the GetOverdueRemindersForVehicle handlers. By doing something like this, it is possible to have simple domain models without needed to worry about converting its internal collections, as the items of those collections are later accessed separately by other means.
Again, which approach you should follow will depends of the requirements of each scenario and your personal preferences.
I hope this helps,
Damian Cherubini
http://blogs.southworks.net/dcherubini