It’s time to get back to the project I was talking about the other day which required some refactoring. I started yesterday afternoon ( our bi-weekly kickoff was in the morning ) and finished modifications early this afternoon. Technically, removing the data objects into their own project was done yesterday too; that was the easy part! I also took the time, since I was already in modification mode, to change my databinding techniques. Rather than using an ObjectDataSource my views must implement a bindView method, which gets called from the presenter on initialization. From the bindView method I call the data retrieval methods. It seems much cleaner, and it removes the necessary reference of my data objects from the UI project.
Now, as you can guess from the title of this post we’re making use of the MVP pattern to build this project, the passive view pattern to be exact. My first impressions of this pattern were a little fuzzy, I was trying to figure out why this was better than using MVC ( As I side note, I tried MS’ MVC framework a few months back and was pleasantly surprised — It reminded me a lot of the Zend framework ). When I started implementing the pattern and began writing my unit tests I started to see where this pattern really began to shine. As a side effect though, I have a lot of interfaces and I hope those who touch the code later don’t get entirely confused.
In the passive view pattern, all of your views are dumb. They contain absolutely no logic (or at least as little as possible). The views are only containers for your data, and what happens to that data is the responsibility of your presenter. Obviously when using event driven GUI’s you need a little bit of code in your view, but other than deciding which events to handle there’s basically nothing there. I’ve made a personal call by putting some validation into my views, but that was because I didn’t want to throw away the usefulness of the ASP.NET validation controls. I also continue to do validation in the presenter before anything gets persisted.
The beauty of the pattern, as I stated already, is the unit testing. Since my views are as dumb as they can be the bulk of my testing is done at the presenter and data access layer. I think this is absolutely wonderful since automatic testing of GUIs is a horrible chore! While there are many tools which can help you along the way, it just never seems to be worth the effort. With the passive view pattern I can literally test the same set of events which would be raised through the GUI easily with unit tests.
As an aside I’d like to mention that unit testing, while a great boon to the development community, doesn’t replace the task of testing by yourself. I still test every method I write with as much care and pride as possible. Assuming your code works correctly just because your unit test passed doesn’t mean it works right! I like to view unit tests more as an aid to help me pinpoint when I break things later.
And now back to the downside of the MVP pattern… The complexity! I’m sure this is partially due to the way we’re tackling this particular project, but at the moment we have a lot of assemblies being generated in order to support the pattern:
- Data Objects
- Data Access Layer
- Data Access Interfaces
- Data Factory
- Presentation Layer
- View Interfaces
- Concrete Presenters
- UI Layer
- ASPX Pages
- User Controls (implementing view interfaces)
- WCF Service
That’s the basics of it anyway… And I’m still not sure I’m doing it entirely right. I made the design decision to communicate from presenter to view using only primitives (string, int, etc ). I’ve seen other people use another layer of interfaces for their data objects to facilitate the views using these, and the presenter translating between view data objects and actual data objects. In my opinion this just adds another layer of unnecessary complexity, but there could be a good reason for it as well.
I do think the testability of this pattern adds significant value. The complexity is a side effect, but one which I believe is manageable as long as I keep things clear and concise. All told, I do think the MVP/Passive View pattern is adding value. If I didn’t think so I would have abandoned it early on in the process of development.
