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?

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?

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?

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

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.

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.

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