One area of question for me about DTOs/BOs is about when to pass/return the DTOs and when to pass/return the BOs.
My gut reaction tells me to always map NHibernate to the DTOs, not BOs, and always pass/return the DTOs. Then whenever I needed to perform business logic, I would convert my DTO into a BO.
The way I would do this is that my BO would have a have a constructor that takes a parameter that is the type of my interface (that defines the required fields/properties) that both my DTO and BO implement as the only argument.
Then I would be able to create my BO by passing it the DTO in the constructor (since both with implement the same interface, they both with have the same properties) and then be able to perform my business logic with that BO. I would then also have a way to convert a BO to a DTO.
However, I have also seen where people seem to only work with BOs and only work with DTOs in the background where to the user, it looks like there are no DTOs.
What benefits/downfalls are there with this architecture vs always using BO's?
Should I always being passing/returning either DTOs or BOs or mix and match (seems like mixing and matching could get confusing)?
It depends on what you wish to achieve. I can tell you what I do myself - I have both the DTO and the BO mapped in NHibernate, but the DTOs are mapped as immutable, so I don't inadvertedly update the database without using a BO.
All queries accessible in the WebServices return/accept DTOs.
Whenever updating from a DTO, I do a UnitOfWork, where I load the BO, update the properties from the DTO and save it again if it is still valid.
On the client, I create the BO from the DTO (AutoMapper is definetly a valid choice here) whenever the client needs to modify it. The BO has a ctor that takes all arguments to create it similar to what NHibernate would do.
The benefits are: * Total control over the amount of data that goes over the wire (The DTO's are typically flattened, so only the Id of associated classes are sent in the first call). * I don't have to have the same properties in both * I can mix and match lazy-loading as I wish * I can utilize scalar queries and other calculated properties in the DTOs without creating them in the BO. * I can have several different DTOs per BO for different scenarios.
So, I guess that would qualify as mixing and matching, but with clear guidelines where I do which :-)
Hope this helps.
Maybe you will find this: http://automapper.codeplex.com/ useful too.
I know this is a quite old question, but let me give my "ten cents" about this subject.
When working with with any MVC project (even with Entity Framework or NHibernate), I use POCO for persistence and DTO/ViewModels for intermediate work, because of the flattened behaviour, less data on wire, and last (but not least valuable), they do not expose relations between objects in any way.
I know this may sound like a "silver bullet", but at least it's working for a while for me.
(forgive some english mistakes =) )
来源：https://stackoverflow.com/questions/4636769/using-dtos-and-bos