RE: Presentation Model Question
I’ve been working on an end to end example using MonoRail (I know, just get
it posted Joey!) that can demonstrate one way this can be implemented
and JP has given me the green light to get it posted even though he’s working in
some sample code as well. (I’m sure his example will be much better than mine)
🙂
But I wanted to respond quickly to [Liam’s
questions](http://codebetter.com/blogs/jean-paul_boodhoo/archive/2007/09/28/screen-bound-dto-update-getting-the-terminology-right.aspx#168899) on [JP’s
latest update on screen-specific DTOs](http://codebetter.com/blogs/jean-paul_boodhoo/archive/2007/09/28/screen-bound-dto-update-getting-the-terminology-right.aspx).
Here was Liam’s first question:
“Firstly, isn’t this a violation of the DRY principle?”
Well… it depends. 🙂
It certainly is not right for every situation. But one of my
motivations for using screen-specific DTOs is SRP. Having a
set of task specific/screen specific DTOs can sometimes give you the loose
coupling you need to protect your domain model from being polluted (most of the
time, unintentionally) by UI and/or infrastructure concerns.
If I have to work within a complex domain, I typically like for the
responsibilities of the domain model to be narrowly focused on object
interactions and relationships to make it easier to understand and maintain.
Now, if your DTOs are nothing more than mirror images of your domain model,
then that is definitely a smell and is most likely not very DRY. I’ve been on a
couple projects like this and, at that point, maintenance of the mapping layer
becomes very tedious and generally makes developers unhappy. Not a good thing.
Liam’s second question is something I’ve been looking for/working towards
myself:
“Secondly, is there a nice way to handle the mapping between the domain model
and the presentation model?”
This is a very good question. So, of course, all of this does come with a
price. Maintaining a mapping layer is usually a necessary evil if you choose to
go this route. I try to start out with simple hand-rolled mappers and let it
evolve from there. Most likely, through continuous refactoring you could arrive
at a fairly robust and somewhat easy to maintain mapping layer. I feel like I’m
getting close to that point on my current project now that I have a dozen or so
mappers implemented.
Unfortunately, I don’t know of any decent frameworks out there that can
tackle this problem of domain-presentation mapping the same way, say NHibernate,
solves the object-relational mapping problem. If you know of any, please let me
know. Otherwise, I suppose it wouldn’t be too hard to “harvest” one from an
existing application. In fact, I may try to do just that on my current project
if I can see any value in it.
You’re probably saying, “Just post some code Joey!”. I know, I know. Well,
I’m pretty close. I just like to make sure the quality of the samples I
provide are close to, if not the same, as the code I churn out every day. So,
thanks for your patience. 🙂