You are welcome.
Yes, data transfer objects and domain/business objects are equally important.
In some situations, it may be possible to use the actual domain/business data object in the Presentation-tier (View) and this may seem like an "efficient" and "time-saving" design. However, you may risk corrupting the domain/business data object model by having to support View and Presentation-tier requirements, i.e. non-business requirements. Either as system is initially designed or in future as things change.
As mentioned in my earlier post, the data transfer object and the domain/business object have different purposes. Attempting to handle these effectively and efficiently with a single Class design conflicts with good design practices, the reasons for DTO design
pattern, etc. If you can do it and consider and address system extensibility, scaleability, manageability, maintainability requirements for the coming three to five years, then yes, it may be a redundant activity and an exceptional situation.
Either way, if you can do it once, this doesn't mean that
you should do it every time. Each system is different and will have different business requirements and different presentation requirements. Personally, the extra time needed to write code for DTO classes is trivial.
When the business application needs to support multiple Views, e.g. PDA, HTML browser, Desktop application, command-line, each one with its own set of Presentation-tier requirements, would you still be able to use a single domain/business object class design and use it as a DTO for all Views?