CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jean-Paul S. Boodhoo

Develop With Passion

Screen Bound DTO Update (Getting the terminology right)

I am going to be posting a small sample that demonstrates what I was talking about in my post describing using Screen Bound DTO’s Presentation Model.

In chatting with a couple of people, they correctly fixed my terminology to use lingo that most people have already got a cursory knowledge of. So with that said, the technique that I described with regards to objects that are designed specific to the screens that they are servicing is the concept of a Presentation Model. DTO’s are still in the picture with respect to the messaging that can occur between presenter and service (and vice versa). The presentation model is their to satisfy the needs of the UI, be if for databinding or other UI needs (such as coloring for rows in a grid, highlighting customers with bad credit etc).

Ok, now we are all on the same page.

 



Comments

Jeremy D. Miller said:

A bit more on Presentation Model for WinForms:

codebetter.com/.../build-your-own-cab-part-5-the-presentation-model.

Microsoft is de facto pushing for a Presentation Model approach with Acropolis and WPF, but they call it something different.

# September 29, 2007 12:09 PM

Liam McLennan said:

I think this is a very interesting idea, but two things trouble me. Firstly, isn't this a violation of the DRY principle? Secondly, is there a nice way to handle the mapping between the domain model and the presentation model?

# September 29, 2007 7:57 PM

joeyDotNet said:

RE: Presentation Model Question

# September 29, 2007 9:03 PM

Jean-Paul S. Boodhoo said:

@Liam,

This is definitely not violating dry as the two models exist to serve different purposes. The presentation model is often much less complex and hierarchical than a rich domain model. The presentation is there to serve the needs of the UI, and the UI only. The domain model encapsulates business rules and rich associations/interactions with other objects in the domain model.

As far as   mapping is concerned. There are several ways that you can handle the mapping between domain/dto and presentation. Driving out the presentation model pieces in a test first manner could allow for you to drive out mappers in a test driven fashion at the time you actually need to perform the mapping from domain/dto to presentation. If you start to see duplication between mappers you can move to a metadata based mapper that leverages reflection to map from one object/set of objects to an object in the presentation model.

# September 30, 2007 1:34 PM
Check out Devlicio.us!

Our Sponsors

Proudly Partnered With