DTOs vs. MVP

I’ve been spewing a lot of mental diarrhea into the porcelain veneer of my blog over the last couple of days, but I’ve still got at least one more post to make before I revert back to my regular twice-per-month posting schedule. Here goes…

As I’ve stated in other posts, on my current project we generate screen specific DTOs from our facade layer that are then directly consumed by the presentation layer. Everything our GUI needs is within those DTOs (and hopefully nothing more). We write our tests (almost 12,000 of them now) to directly assert on the values contained in those DTOs, making our presentation layer as thin as possible. In essence, we’re attempting to test as close to the GUI as we can, which should surprise nobody. Since the GUI and all that it does is specified directly by the clients, testing our DTOs should go a long way towards making sure they are actually getting what they are paying for. We then run some watir-driven smoke tests before each checkin to make sure nobody accidentally forgot to change a property reference in the JSP.

Now there’s been a lot of hype, in the .NET community at least, regarding the Model-View-Presenter pattern. I actually like the pattern itself, but my main question lies in whether it should be used as a replacement for a pattern such as our “screen DTO,” or does it work with it?

Jean-Paul Boodhoo of Thoughtworks recently did a screencast on MVP, and as far as I can tell he’s using the MVP pattern in addition to a screen DTO approach. It seems like you’d have to first assemble the DTO below the Facade, and then essentially assemble the View directly from the DTO. It seems to me like the Presenter is actually just an assembler sitting outside the facade. So why have both? Am I missing something?

2 thoughts on “DTOs vs. MVP

  1. Jean-Paul S. Boodhoo

    Hey Jeff,

    Thanks for the props over at codebetter by the way!! You should check out my new video I just posted up at my blog and that should hopefully start to answer you question. Because I am coding using a top-down approach,all that my first test is ensuring is that the presenter talks to the “service layer” which in turn (when I get to it) would be responsible for assembling and returning DTO’s to the presenter based on domain data. In the first video the only responsibility the presenter has is to push the corresponding list of DTOS to the view. It does not assembling whatsoever. A majority of DTO assembling done in a presenter is creating a DTO (based on view information), that can be sent as a packet to some service layer method. The other scenario where a presenter assembles is when there is a common DTO shared between multiple screens, but each screen needs to display the data in different ways (ex. Format currency differently etc). In this scenario, it can often be more effective to create an IScreenDTOAssembler interface, with each implementation knowing how to convert the CommonDTO into an appropriate representation for the screen that is currently working. This is actually great if you are actually sharing the presenter between the multiple screens as each screen can construct the presenter and pass in the assembler that the presenter should work with:

    public class SomeSharedPresenter
    {
    public SomeSharedPresenter(IView view,
    IScreenDTOAssembler assembler)
    {
    }
    }

    Anyway. I’m rambling. I’m right here in Calgary so you should give me a call (560-3590) if you want to chat about some of these concepts.

    JP