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
on JP’s
latest update on screen-specific DTOs
.

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.  :)

 

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

This entry was posted in domain-driven design, nhibernate, patterns, refactoring. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

7 Responses to RE: Presentation Model Question

  1. Joe Ocampo says:

    >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.

    I don’t either! I usually have to make my own. Lets make an Open Source Project that can do this! Anyone else in?

  2. I’m currently using a domain entity < -> DTO approach (mirrored) but I’m using SubSonic to generate my code, so I just modified the templates to allow marshalling/mapping between the two.

    In this scenario, it’s dead simple, but then again doesn’t add a whole lot of value.

    I’m really interested to see if the Presentation Model is more fitting for what I’m trying to do.

  3. Jeremy says:

    @Ben,

    The main reason to split off a separate Presentation Model from the Domain Model is because the two things need to be different. Like using a Presentation Model as a flattener, or keeping extra state that only pertains to the view like “ThisButtonEnabled” or “SizeOfTheSuchAndSuch.” I’m not too sure that a codegen approach gets you too much here.

  4. joeyDotNet says:

    @Ben,
    Yeah, I haven’t attempted a codegen approach to this problem yet. Like Jeremy said, I often do have properties on some of my DTOs like “FreeOptionShouldBeEnabled”, “ShouldAllowQuantityToBeUpdated”, etc. which I’ve found fits nicely in the presentation model.

    The interesting part for these scenarios is that most likely the value that gets assigned to these screen-specific attributes is based on 1 or more business rules that are encapsulated in the domain. Like, “CheckoutButtonShouldBeEnabled” might be set based on an IsReadyForCheckout method on your Order domain object or maybe it uses a service call to make that determination, etc. Either way, the implementation of that logic stays nicely separated from the presentation layer itself.

    One thing I’m still mulling over is the fact that sometimes your domain-dto mappers have to be “smart enough” to at least know which domain object or service to call in order to set the appropriate DTO values. For the most part, I like my mappers to stay pretty dumb, but I am looking for a more elegant solution for dealing with “smart mappers”.

  5. Joe Ocampo says:

    > Like, “CheckoutButtonShouldBeEnabled” might be set based on an IsReadyForCheckout method on your Order domain object or maybe it uses a service call to make that determination, etc.

    Curious wouldn’t this simply be a Specification or Constraint object since it is a predicate evaluation within the Domain.

    >For the most part, I like my mappers to stay pretty dumb, but I am looking for a more elegant solution for dealing with “smart mappers”.

    Couldn’t this be achieved by using Spring.Net and giving the DTO an aspect when it’s behaving this way etc. Use this mapping?

  6. joeyDotNet says:

    > “Curious wouldn’t this simply be a Specification or Constraint object since it is a predicate evaluation within the Domain.”

    Indeed. The examples I gave were just to merely point out that the mappers would need to have at least enough “smarts” to communicate with the domain in some way. This kind of logic would most likely be encapsulated in some sort of specification *in the domain* that perhaps is injected, if necessary, into the mapper implementation itself.

    > “Couldn’t this be achieved by using Spring.Net”

    If you’re talking about managing the mapper *implementations* in an IoC container, then yes, those are already managed via my IoC container (Windsor). This definitely makes them easier to swap and and extend (i.e. decorators, etc..) if necessary.

    Right now my “service” implementations get injected with the appropriate mappers as necessary and the service methods take care of invoking the mapper when needed to translate to/from the domain/dto.

    > “giving the DTO an aspect when it’s behaving this way etc. Use this mapping?”

    Could you elaborate on this?

  7. Colin Jack says:

    > Lets make an Open Source Project that can do
    this! Anyone else in?

    I’d certainly like to be involved in an open source project for this, it definitely seems like something people will find useful.

    > This kind of logic would most likely be
    > encapsulated in some sort of specification *in the > domain* that perhaps is injected, if necessary, into > the mapper implementation itself.

    I’m confused, why would you inject this in? Do the DTO’s not have a dependency on the domain so why would you be injecting them in?

    >This definitely makes them easier to swap and and
    > extend (i.e. decorators, etc..) if necessary

    Just interested, why would you want to extend/replace the mapper?