]
07-22-2023, 10:38 PM
I've seen a lot of questions related to mapping [DTOs][1] to Domain Objects, but I didn't feel they answered my question. I've used many methods before and have my own opinions but I'm looking for something a little more concrete.
**The Situation:**
We have many domain objects. We are using a CSLA model so our domain objects can be pretty complex and they contain their own data access. You do not want to pass these around on the wire. We are going to be writing some new services that will return data in a number of formats (.Net, JSON, etc.). For this (and other reasons) we are also creating a lean, data transfer object to pass around on the wire.
**My question is: How should the DTO and Domain object be connected?**
My first reaction is to use a [Fowler, DTO pattern-type solution][2]. I've seen this done many times and it feels right to me. The domain object contains no reference to the DTO. An outside entity (a "mapper" or "assembler") is called to create a DTO from a Domain Object. Normally there is an [ORM][3] on the domain object side. The downside of this is that the "mapper" tends to get extremely complex for any real situation and can be very fragile.
Another idea put forth is for the Domain Object to "contain" the DTO, since it's just a lean data object. The Domain Object properties would internally reference the DTO properties and could just return the DTO if asked for. I can see no problems with this but it feels wrong. I have seen some articles where people using [NHibernate][4] appeared to use this method.
**Are there other ways? Is one of the ways above worth using? If so or if not, why?**
[1]:
**The Situation:**
We have many domain objects. We are using a CSLA model so our domain objects can be pretty complex and they contain their own data access. You do not want to pass these around on the wire. We are going to be writing some new services that will return data in a number of formats (.Net, JSON, etc.). For this (and other reasons) we are also creating a lean, data transfer object to pass around on the wire.
**My question is: How should the DTO and Domain object be connected?**
My first reaction is to use a [Fowler, DTO pattern-type solution][2]. I've seen this done many times and it feels right to me. The domain object contains no reference to the DTO. An outside entity (a "mapper" or "assembler") is called to create a DTO from a Domain Object. Normally there is an [ORM][3] on the domain object side. The downside of this is that the "mapper" tends to get extremely complex for any real situation and can be very fragile.
Another idea put forth is for the Domain Object to "contain" the DTO, since it's just a lean data object. The Domain Object properties would internally reference the DTO properties and could just return the DTO if asked for. I can see no problems with this but it feels wrong. I have seen some articles where people using [NHibernate][4] appeared to use this method.
**Are there other ways? Is one of the ways above worth using? If so or if not, why?**
[1]:
[To see links please register here]
[2]:[To see links please register here]
[3]:[To see links please register here]
[4]:[To see links please register here]