As the non-existent avid reader of this blog will know, I’m far more interested in learning new technologies than I probably should be, given the limited amount of time I have to learn them properly! With that in mind, I shouldn’t be looking at yet another, but this one does have a very immediate benefit (honest).
I have been an ASP.NET developer for quite a number of years, and can knock out a complex web site fairly quickly. However, as with most of my other programming until recently, this has always been along the “throw it all in the code-behind” anti-pattern. I’ve come a long way in the last six months or so, and am now very comfortable using MVVM in WPF, and separating out my code into logical classes as all the Good Programmers do.
Logically therefore, my web site development should follow the same lines. I read up on both MVC and MVP, and came to the conclusion that as an experienced ASP.NET developer, MVP made a lot more sense to me. I couldn’t honestly see any technical benefit of one over the other, mainly as the MVC proponents seem to raise the same old “webforms are evil” arguments, without any real justification (to me at least, they obviously feel justified). My own feeling was that MVP wins out because it completely isolates the view from any action, meaning that the view is as dumb as it can get, which makes unit testing a doddle. I was won over towards the Passive View version of MVP, as this has even less code in the view than the other flavours.
This is not to say there’s anything wrong with MVC, just that I feel more comfortable with MVP.
The other reason I felt more drawn towards MVP was that I like the convenience of WebForms. It seems that this is a rather contentious issue, with the anti-WebForms camp decrying them as evil. As with most arguments over programming-related technologies, people can get quite religious about this. As I have yet to see any genuine arguments against WebForms, assuming you know how to handle view state that is, I am left with the significant benefits of having a lot of work done for me. If you know how to use them, the supposed arguments against WebForms are easily dismissed, and you can write site with good quality, valid (X)HTML using them. Aaron Powell does a good job of defending WebForms on his blog. Typical of the arguments against, is this blog post, where the author grudgingly admits that most of Aaron’s arguments are valid, and says that he doesn’t like WebForms because they encourage “robot developers.” Oh dear, is that the best argument you can come up with? If you follow that one to its logical conclusion, we should all be writing in assembler code, using Vi or Edlin! Any technology can be used properly, or abused by people who don’t learn how it works. I’m sure there are plenty of absolutely awful MVC sites out there, but it doesn’t mean that MVC itself is bad.
Oops, I seem to have waffled on for longer than I intended. Either way, I have settled on MVP for the moment, and was looking for a way to increase my efficiency at producing MVP-based web sites.
I started off writing my own code to do the job, but then came across a mention of WebFormsMvp in a book I was reading (the rather excellent “Professional ASP.NET Design Patterns” by Scott Millet). Interested in a framework that did the plumbing for me, I scuttled across to the web site… and was immediately disappointed! There is a great introductory video on the site, and a page of (supposed) learning resources, but no real documentation.
I downloaded the code and started playing around with it, but couldn’t get my head around what was going on. I had a look in their forum, but was disappointed by the very low amount of activity, and the number of unanswered questions. Nevertheless, I persevered, but eventually came to the conclusion that I was wasting my time. I went back to writing my own code.
For some reason, I decided to go back and poke around the forum again. I guess I’m a bit of a nark sometimes, and was annoyed at the lack of documentation. I wanted to vent my frustration, and so made a few caustic posts in complaint. Apart from a few nods of agreement, I did actually get some help out of this, and this encouraged me to continue. Sadly, other things got in the way, and I had to leave this line of investigation.
However, given that I am in the early stages of developing a new web site, I decided to spend a little extra time, and try using this framework on that. This gave me the justification to stick my head in the WebFormsMvp code a little more deeply, and I’m glad to say, it finally paid off! After some digging around, and some questions in the forum, I worked out how to use it, and found that it was actually a pleasure! The amount of time it saved was quite impressive.
Not being one to leave code unfiddled, I decided to extend it, and create my own classes to do even more of the plumbing than WebFormsMvp does already. It could be that someone else has already done this, but I couldn’t see any evidence of this, and it was good experience for me.
The current position is that I can create a view very quickly, and the WebFormsMvp together with my extensions will create the presenter and repository automatically, so I don’t have any plumbing code to write. In many cases, my view is entirely codeless, and even when I need to write code, there is very little, and it’s so simple that testing is simply not necessary.
One of the WebFormsMvp developers made a tantalising post in the forum, where he said he was working on a feature that would reduce the amount of code needed even further. I haven’t managed to try this out yet, partly due to lack of time, and partly due to not being quite sure how to get at the code he’s provided! However, I’m confident from what I’ve seen that this will make web development even easier, leaving me to concentrate on the interesting bits of a site, not the plumbing.
In a future post, I will describe how to use WebFormsMvp, my extensions to it and so on. I think this post has been more than long enough (and I’m supposed to be working), so I’ll leave it here for now.