Screen Bound DTO’s (Presentation Model)

Currently, in a lot of the projects that I work on I tend to take a top down approach to development. Which means that I will start at test that focus on the presentation layer of the application.

Some people are curious as to this approach. My answer for this is simple. From the customers perspective, the first and simplest entry point to the application is the UI of the application itself. The UI also happens to be the place where developers spend a lot of their time, as that is often the place of most contention because of user expectations for how the UI should behave. By focusing on presenters and their accompanying view implementations, I can focus on stubbing out the behavior of the required service layer pieces as well as the accompanying Screen Bound DTOS that are required to present data to the particular user interface.

The concept of Screen Bound DTOS is probably not a new one, but one that I have been able to use with lots of success. Most people who look at my code are probably aware that I favour the use of DTOS with regards to use in the presenter to service layer communication as well as for displaying data in the UI. This is because you can build DTOS specific to the screens that they are going to service. They are completely separate from the underlying domain layer that will ultimately handle the business logic, and therefore are completely unaffected when a change to the domain model actually occurs. When a domain object or set of domain objects that ultimately map to a DTO change, the only thing that needs to change is the mapping from domain to the DTO. This ultimately allows my domain to evolve completely independently of the needs of the user interface.

Also keep in mind that a given screen may have the concept of more than one type of DTO for the different behaviours that can occur. For example, when I am displaying a list of products to purchase in an online store, I may have the need for a DTO that consists of the name, description, and price, as well as the SKU number for the product. When it comes time to add an item to my cart, what are the pieces of information that are really relevant to pass to the service layer? Only the SKU and the number that I want to add. I can encapsulate this information in an AddItemToCartDTO that contains the sku of the product and the quantity to be added. This DTO is free of all of the extra noise that existed in the previous DTO that is not necessary for the add to cart behavior

With regards to the presenter to service layer communication, these DTOs become essentially stripped down commands without the behaviour necessary to complete the task.

Using this technique and Top Down Development, I can completely finish off a screen, hand it off to the user to verify that it works the way that they want. I can do this by stubbing out service layer implementations to return fake data.

Once I get sign off from the user that the screen is up to par, I can now switch down to another layer and repeat the process of Top Down Development, from a different layer in the application.

 

This entry was posted in Programming. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

10 Responses to Screen Bound DTO’s (Presentation Model)

  1. Colin Jack says:

    Personally I believe that this sort of DTO/Presentation Model approach is not always needed and that if you can get away with using your domain objects in the GUI then you should do that because its simpler.

    Can I ask how you do the mapping, do you use code or a framework with its own custom mapping file format?

    I’m also interested to know how do you test the mapping. I believe you don’t favor mocking your domain objects so do you just create the domain objects, map them to DTO’s and then test the state of the resulting objects?

  2. Bobbert says:

    I agree with Joe and Glen. I’m not totally sold and would love to see a working example.

  3. Glen G says:

    I agree with Joe … an example of how this would all come together would be great.

    Any volunteers? Or any links that anyone might have would be useful.
    Cheers!

  4. Joe says:

    Would anyone care to show an example of how this works in code? It sounds like a good idea, but Im a little confused about how you maintain the mapping and where the code for that would sit, project/solution0-wise?

  5. Just like Joey said, this works great for data binding. I’ve used this technique with great success in WinForms applications. From the data binding perspective, it is also easier to bind against a view-only domain object because you don’t have to worry about a deeper object hierarchy. Deeper object hierarchies are at least more difficult to work with when binding.

  6. sr says:

    I would be interested to know how you have found this approach scales when you have more client side functionality i.e. workflow and UI process logic (for example for a SmartClient app).

    Do you use the DTO’s to populate/bind to the UI directly?

    I have been looking at a similar approach for relative thin client layer – with the client side DTO objects generated from the web-service proxies. You can add some validation logic to the generated classes (using partial classes and IDataErrorInfo for example). But this is a bit limiting.

    Or do you think the DTO objects shoud remain as is.

    However for a complex app I can’t help thinking you would want to map to a client side object model (ViewModel) . But the judgement is when to make that jump – and the associated overhead.

    The top-down approach seems a good approach for the right project (i.e agile / semi agile – early prototyping)

  7. joeyDotNet says:

    This is exactly the approach I’m taking on my current project and it’s really working out well. Especially when you can let MonoRail do the databinding to DTOs for you from the view.

    Then you can be explicit about creating DTOs for “display” purposes only (which most of time can be immutable) and DTOs for “editing” which are populated from the view (which could also be immutable if you’re using a databinder that is able to utilize a constructor during creation, which MR’s can’t right now, AFAIK).

    Maintaining the mapping layer is a necessary evil when using this, but you could most likely automate it somehow.

  8. Based on your discussion of this technique at the Nothin But .Net course I’ve started using the same technique and I love it.

    One thing you mention is change to the domain but this also insulates you nicely from changes to the screen. The project I’m currently on doesn’t use this technique so every time you ant to make a change to a DTO you need to find all the usages of it and make sure you’re not going to break anything. Nasty to say the least even with Resharpers assistance.

  9. jdn says:

    I agree with this approach completely. It avoids a number of problems, one major one being that even when you talk through user stories in some detail, often times end users think of domain objects at the UI level.

    DTOs allow you to quickly and properly test and populate the UI (which, let’s face it, is more often than not ‘the application’ for many), without worrying about tying yourself to some poorly thought out domain.

  10. Hey,

    You “automate” the conversion between Dto and domain objects ? I mean, you use some helper to make the conversion or you have 1 converter for each pair.

    If do the last… this process takes long time to you?

    Thanks and regards

Leave a Reply