Ah...so continuing my search for the perfect architecture (joke) my current issue was the usefulness of Data Transfer Objects (DTOs) at my last post
. I am still dumfounded when I find what might be considered "high-ranking" Microsoft folks admit to either ignoring or knwoing little about design patterns. I know design patterns are just a means to an end of good software delivered timely and fit for scalability, but it seems like they should at least be in the toolbox...but I digress.
My current confusion is the best way to send values from a web page to a Service Layer/Facade that sits atop my domain layer. One proposition is to employ Data Transfer Objects...kind of shallow, behaviourless objects that resemble my Domain Entities... and send those back and forth. My main gripe with this is simply the fact of maintaing two objects with teh same fields...a Lone Ranger developer looks at that and says YECCH.
One nice thing about these DTO's is the cleaness they would seem to promote in the client's code that consumes them....rather than sending a million primitive types to the service layer/controller, the primitive types would be zipped up in a DTO and sent to the service layer. But one thing that dawned on me is that this seems to point to a need for greater granularity in my service layer/controllers. If I have a finer-granularity for access to my Domain Entities via ServiceLayer, that would seem to reduce the large number of parameters getting forced into my Service layer.
Since I am not distributing this app and don't ahve plans to expose as a web service (yet), the DTO plan seems heavy-handed just too dang much to maintain as changes occur. Messages have to get sent somehow to the service layer, though, so the possible solution is to revamp my controller layer toward even higher cohesion. This should become obvious by the presence of what Larman calls "bloated controllers" in his Applying UML and Patterns
book. So Off I go to breakout my facade into smaller bites....