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?