September 2006 Entries

UIPAB Survey

 

The patterns & practices team is currently holding a survey about the direction of a new project aimed to fill the gaps and extend where the UIPAB left off. I am curious if they will be integrating Windows Workflow into the project as it seems to be a good fit. At TechEd this summer there were several presentations on Windows Workflow within ASP.NET by the ASP.NET team, hopefully Microsoft isn't creating two different projects with the same goals in mind. This wouldn't happen would it - Windows Communicator, Windows Messenger, MSN Messenger ;-) Go ahead and let them know what you think.

Mock Object Discussion

 

Scott Hanselman has a great discussion on mock objects on Hanselminutes. They go over the basics of how mocks fit into the development environement and how it helps in a test driven development environment. Scott mentions how the Expect API of many mock object frameworks read like an english sentence, this is a great example of a fluent interface. Scott points out one of the most apparent reasons why Rhino Mocks is a great mock library, it doesn't rely on string-based method names, you actually use the method in your expectations. This is great because it allows developers to lean on the compiler, this can be especially useful as you refactor your code base

Model View Presenter Redux

 

The Model View Presenter (MVP) pattern seems to be all the rage within the last year; it must be the new pink. While I agree this is a great pattern to decouple various logical layers within a system, I think we are missing an important core piece to the puzzle.

In my opinion, humble of course, the Model is purely a representation of my data, and I prefer to depict that in the form of a Data Transfer Object (DTO), this is the ubiquitous PONO (Plain Old .NET Object) - (Edit: Domain Model's are welcome too) . The View is typically defined as an interface that my UI will provide as implementation. The Presenter will then orchestrate the interaction of my Model to my View. But wait, where does my Model come from? This is where a Service layer comes into play. While there are many different terms for this layer, this layer is responsible for extracting our Model from somewhere (i.e., service implementation). Most commonly, our Presenter will perform specific requests from the Service layer in its orchestration process. I would like to refer to this pattern from now on as MVPS (Model View Presenter Service). I’d love to hear feedback on this, in particular if you don’t agree with me – who doesn’t love a hearty debate?