DTO or Domain Model Object in the View Layer?
It really depends on the complexity of your application. Mixing domain objects into the view layer has two possible implications:
- You'll be tempted to modify your domain object to accommodate things you need in the view layer
- Your View layer will contain extra complexity caused by a mismatch between what your domain objects offer and what your view really needs. You might not be able to get around this complexity but it probably doesn't belong in the View layer.
If your domain objects are simple and your views are few, skipping the DTOs might be the simplest thing.
On the other hand, if your domain model is likely to evolve and become complex and if your views are likely to be numerous and varied, having view specific objects might be a good idea. In the MVC world, using ViewModels is common and makes a lot of sense to me.
Another vote for domain objects. As far as Domain Driven Design is concerned the domain model is the king and should be used where possible. The application should be designed in a way where most layers (bar Infrastructure layer) can use domain objects.
I think of DTOs as useful only where the objects need to be serialised. If there is no transfer over the wire or into an incompatible architecture I would not use them. DTO pattern is useful for keeping serialisation out of the domain object. Considering that UI/Domain interaction does not need serialisation, keep it simple and use the actual objects.
I think having DTO is not generally an anti pattern. There are a lot of people and systems using them and the benefit you get is the decoupled view layer that can be designed and modularized independently from the domain model. Although I agree that you should use domain objects where possible there are scenarios where you can get problems when you tie the view layer directly to the domain model.
I have made good experiences with a view model that only wraps around the domain objects and delegates most of the operations to them.This decouples view and domain layer, allows for flexible composition of domain objects and still is not much work to implement since IDEs support delegation pattern.