I am flogging the dead horse about Data Transfer Objects (DTO's), also called Value Objects, and their usefulness, picking up on what I discussed in my last post. Using NHibernate on my current project, the topic of DTO's and their validity was incited by the Hibernate In Action position that DTO's are suspect in regard to their compliance to OOP. Fowler (he has to be mentioned, right?) himself calls them beasts and focuses on their usefulness for clients utilizing the domain objects across a remote boundary; in otherwords, shield the domain layer from direct exposure by remote clients AND reduce the number of calls for fetching/sending data for processing. Since I am not real concerned about remote access to my domain (ok...never say "never"), at first glance maintaining what seems like a parallel framework to my domain model seemed like just another thing I have to maintain and code. The DRY principle shudders at a DTO at first glance.
Since the two logical options for sending data to my Service Layer from my (web) form are either method calls accepting parameters from my code-behind, or creating a DTO framework for (duh) transferring data between layers. It is true that Fowler is primarily concerned with interaction between processes in his PoEAA book, but another benefit of DTOs emerge that simple calls to teh facade layer emerge in regard to notification of errors/messages/whatever during commands in the Service Layer. The Notification pattern is a great clean way to send meaningful messages between the UI and service layer. In Pierre Greborio's post, he has a great implementation of this pattern if you intend to directly use your domain objects in your view classes. It is possible using this pattern to abstract away the extraction of Notification messages after calls to your service layer and standardize their presnetation across a whole website very succinctly, as Pierre is proposing. Still, somethign seems wrong to me to introduce these kinds of responsibilities into even a layer supertype for my domain classes...The DTO seems to provide the kind of abstraction I want for having a standard way for all messages to be returned to my client after some command AND fits into the responsibility for which it is designed - transferring data (sending messages across the wire is a message).
The notifications I'd like to receive back from my domain would seem to be difficult to obtain from a Service Layer that is a singleton...do I have all my Service Layer method calls return an array of strings containing those messages? I am not going to use out parameters since they seem to confuse some developers.
Are there any patterns someone has had success with for standardizing messages that are accumulated during calls to a domain layer from a UI layer WITHOUT using DTOs and WITHOUT messing around with out parameters and WITHOUT returning a mess of string arrays?
The DTO solution seems to emerge (for now) as a winner (darn it!). Separation of concerns is enforced ... I admit that by having domain objects in my views I would slide on where biz rules were enforced (short-circuiting my service layer). DTO's would totally remove that tempation. But that's a discipline problem, not a need for a pattern. DTOs are certainly cleaner than firing off a bunch of primitive types to my service facade AND give me the benefit of a clean Notification pattern across all boundaries.