(Chalk this one up to lessons learned...)
I recently made the comment to a co-worker that the more applications I develop, the more layers and complexity I seem to be removing and the more I'm striving for simplicity. At first glance, this may look like a step backwards to those caught up in BDUF and designing a complex layering scheme for what you think the application is going to need.
But even if you're trying to emerge the design as you develop, you can still be tempted to prematurely inject layers of complexity that aren't warranted. As you can probably tell if you read one of my previous posts, we are using DTOs, perhaps when they aren't needed.
Like on one of my current projects, I started out with a pretty typical architecture (non-distributed):
- web ui
- presentation layer
- using one of my favorite patterns, Model-View-Presenter (right now I lean towards the Passive View flavor of MVP for its increased testability, but I can see how using Supervising Controller might be a good choice for windows forms apps if you actually like databinding... :)
- services
- domain
- data access layer
- you know, that layer we all hate writing over and over again (can't wait to actually use NHibernate on a real project)
So the basic gist of it is my presentation layer uses different services to perform operations using my domain objects and my services take care of shoving stuff in and out of my data access layer.
Well for some strange reason I got on a DTO kick and prematurely injected a set of LocalDTOs to hide my domain objects from my presentation layer. I thought it would be nice to separate how the data is represented in my presentation layer from my actual domain model. Turns out this flexibility comes at quite a hefty price. I suppose I should've known this going into it when I found this quote in PoEAA...
"Don't underestimate the cost of [using DTOs].... It's significant, and it's painful - perhaps second only to the cost and pain of object-relational mapping"
Perhaps if I would have read this post by Jon Tirsen and Fowler's response, it would have persuaded me away from my attempt at improperly applying the DTO pattern to my application. The mapping logic that needs to be written and maintained in order to support this pattern can be tedious and downright frustrating. However, if you're in a situation where you have to use DTOs, you should check out the BLToolkit which has a nice mapping engine which will definitely ease your pain.
Bottom line is that I decided to remove this layer of complexity from my application by refactoring away from this pattern and boy am I glad I did. Now I can use my nice rich domain objects in my presentation layer which will really speed up future development and lower maintenance costs for this system.
So, remember, whenever you feel compelled to introduce another layer of abstraction or apply some new cool pattern you just learned about, make sure you're not over-architecting and you're KISS. :) (Refactoring is your friend...)
Well looks like I only got to the DTOs portion of my title, so I'll tackle Data Contracts and Accidental Complexity vs. Essential Complexity in subsequent parts.
Happy TDD'ing!