I am currently in the finishing stages of an Ektron project that utilised the
Webforms.MVP framwork. About 18 months ago, I saw
Tatham Oddie talk at a Redify Developer Day, he introduced Webforms.MVP as a project created by himself and
Damian Edwards, the culmination of working on several webforms projects.
There have been several other attempts to integrate Webforms.MVP into other CMS’s, including
EpiServer,
Umbraco and
DotNetNuke.
We work with complex HTML/JS/CSS, so one of the goals was to have maximum control over markup, traditionally a hard task with both Asp.Net and Ektron controls, whilst still being able to leverage out-of-the-box Ektron controls.
Advantages
- Testability. Views can be mocked, presenters hit, and the simple models asserted against.
- Separation of presentation logic from business logic. The constraint of aiming to keep the code behind spare really helps to achieve simple and pleasant controls. The separation also helped conceptualise and enforce a business logic layer.
- Ability to use mix and match any combination of MVP, Asp.Net and Ektron controls within a page.
- Simple to use Pub/Sub messaging bus.
- Easier to avoid amorphous View State blobs.
Disadvantages
- Documentation is a little light There is a couple of good screencasts, and the sample code is great to start with, but a little lightweight (I’m hoping to add some sample code when I get some time).
- Development is slower, though I believe this could be mitigated by creating code templates or using a code generator.
- Fair bit of left-hand/right-hand code, though this could be mitigated by AutoMapper and refactoring some of the view-models.
- Medium learning curve, not a typical Webforms project.
With regards to testability, unfortunately, the number of tests on this project is one (and that test is nowhere near the MVP stuff). Our dev shop is, like many web forms developers, naively unaware of testing.
IOC is the group in charge of the Olympics, and
mocking is a type of song bird. Between this and the tight deadline, TDD was abandoned and unit-tests were moved into 2.0.
Against all the militant cries of “
untested code is broken code”, this was the right business decision, and it highlights a common problem faced by one striving to improve coding standards – time. The fresh effort of learning TDD practises would have made an already late project even later, and there is no requirement that you ship perfect code (this isn’t a web interface for a
Therac-25). I want to strive for quality, but need to either learn to settle for a little less, or improve efficiency. The latter takes time, so I would need to be more efficient at being more efficient. It’s turtles all the way down.
The messaging system was also a revelation. It is a breeze to pub/sub objects, and makes for simple code. We went with using page presenters that would do authentication and publish a user object. Possibly not the best pattern, but a nice way to avoid setting flags etc. in complicated master pages.
Probably the biggest mistake of my current project was that we only used Asp.Net and Ektron controls sparingly. This gave us wonderfully bespoke markup, but at the cost of time. For example, our hand-rolled forms meant that we couldn’t easily use server side controls, and therefore we also had to hand-roll our validation. This was also exacerbated as I wasn’t able to get the ‘convention over configuration’ quite working, so each view had to be attribute decorated (on the plus side, this made it easier to jump to the present/model via F12). Maybe some of the smaller pieces could have been done without MVP, but in some ways this is when MVP shines- I really like close-to-the-road feel of <span><%= Model.FirstName %></span>.
One thing not explored was getting our frontend developers, who usually design in PHP and pure HTML, to directly update templates. The new-found simplicity of the templates makes this possible, but the increased setup time and system load for a local Ektron dev instance rules it out for now.
When I first mentioned the idea of combining Ektron and Webforms.MVP on Twitter, Martin Jarvis’s
response was “You can certainly use MVP/MVVM/MVC pattern with Ektron API as a repository. I don't know about the UI components.” This was very prescient, apart from occasional ContentBlock controls, all other markup is handmade, with API calls pulling the data. We’ll probably even remove the ContentBlocks in order to add templating functionality for the CMS user. This is partly due to the nature of the project, and partly due to a preference of using MVP over XSLT.
Martin has a
great series of articles on using Web Application Projects with Ektron, which partly inspired this look at MVP. What if we could gain some of the advantages of everyone’s new best friend MVC, whilst still stuck in the webforms world of Ektron (note- the 8.5 release on the horizon appears to offer a lot of overdue goodness which may make Ektron MVP mute. There is talk of a pre-compliable workarea and the tautological MVC controls, which hopefully are actually MVP-ish).
So, for now, if I had my time over, would I do it the same? Maybe, maybe not. The schedule has gone horribly over time, but the site does look good and functions well. I am hopeful, though not necessarily confident, that future maintenance will be easier (alas, a goal that cannot be measured).
Edit 11-Mar- "there is requirement" should be "there is no requirement"
