Choosing a Web Application Server Stack
There's this great book entitled, "The Paradox of Choice: Why More Is Less," that really opened my eyes to a rather non-intuitive way to improve my experience in life. I won't go into it more than to say the author posits that there is an inflection point where "happiness" does not increase with additional accretion of choices. This is non-intuitive, but he does a good job of explaining the many factors underlying this phenomenon. For one, consider the opportunity cost of making a decision; you are buying what you consider the best at the time, but you are also carrying the burden of not having chosen from many other options. Very often, buyer's remorse sets in after a purchase, and we have no one to blame but ourselves.
So, as I tore through blogs, email archives, tutorials, and documentation today, looking for the "best" platform for my personal pet project, I became acutely aware of just how much choice there is available to build web applications these days. The result is that it's very late in the day, my weekend spent, and I am writing this blog post to reason aloud, as it were, and to force myself to pick one.
By way of introduction, let me say that my skill set falls squarely in the tried-and-true .NET 2.0 ASP.NET developer model. I don't do MVC, MVP, Presenter First (PF), O/RM, TDD, DDD, BDD, or any other TLAs, except maybe DRY, SRP, and all those other solid OOP principles. Also, I'm building this application for myself, by myself, and I can't seem to get a free copy of Visual Studio 2008, so .NET 3.5 and LINQ are out of reach. I know I need forums, but that's about my only "requirement". Sure, I've got lots of ideas of what I'm going to build, but I am staring at the blank canvas right now.
Here's the thing: I'm productive. I build good applications. I suspect that probably has more to do with my empathy and diligence rather than some prodigious development or architecture skills. I'm certain I can get better at the latter, but my competitive advantage, if you will, comes from design good interactions. I'm good a UI design and ideation. And, frankly, all those TLAs are a bit intimidating, as is the prospect of writing so much more code.
It may sound like I'm leaning toward an ASP.NET 2.0 application, so let me reflect on that. I am definitely not going that direction. The major strengths of that platform are:
- Tooling support---Visual Studio beats vim an SciTE hands down
- 3rd-Party Controls---Telerik, Infragistics, etc.
- Familiarity---myself and thousands like me use it every day
Those advantages sound great if you are an IT manager building line-of-business applications. That's not me. Among the disadvantages for me are:
- Mundane---I use it for a living and wouldn't be learning anything new
- Visual Studio 2005 is not free and the Express editions are...Express editions
- I won't be purchasing any 3rd-party controls
- The Page-based application model seems outmoded
So, what are my options? Well, I would like to try building an application using the MVC/MVP/PF paradigm. I've invested many hours learning about it, and I want to take a stab at it. This means, almost certainly, using an IoC container--but which one? Also, MVC differs significantly from MVP as does PF; which shall I use? I have to select an environment to do this all in as well.
Supervising Presenter First?
I have settled on Presenter First (PF). This doesn't have the widespread community support that MVC/MVP have today, which means less tooling and "free" functionality, but that's okay. PF takes SRP and the Humble Dialog to the extreme, forcing you to develop a testable presenter that reads like user stories and easily mocked views and models that can also be tested. Because PF dictates an stateless and ignorant view, it should be easy to replace and change the UI. Now, I can definitely say I won't be doing "pure" PF; I plan to allow tuples/ActiveRecord objects into my UI, because I want to use databinding and all the built-in goodness of ASP.NET when it is efficacious to do so. In this sense, I want PF with Supervising Controller leanings.
Views: Plain-old Pages
I believe ASP.NET Pages are a very strong candidate for views, despite what I have heard from the ALT.NET crowd. As a template engine, they are very mature; you can even nest master pages in 2008! The ASP.NET Membership provider (Authentication, Authorization, Personalization, etc.), declarative security, and databinding are a few great things you get out-of-the-box. There are lots of controls out there to work in ASP.NET Pages, including all the ASP.NET AJAX stuff. This absolutely does force you to think about your views in terms of pages at some level, but I believe partial page updates allow user controls to be views as well.
Choosing a Framework
There are lots of choices out there for doing MVC/MVP style ASP.NET application, each with their own peculiar twists. I have mentioned a couple of these before, but here are the ones I've looked at:
The main problem with each of these is that they are not PF pattern friendly. That isn't to say that they are antagonistic, not at all. I'm guessing, relatively blindly, that each of these would be equally difficult to implement PF. So, what other criteria can I use to cull the herd? Well, MonoRail doesn't play nice with ASP.NET Pages, so it's out. Cuyahoga is a real pain in the butt to configure, quite possibly the longest time-to-hello-world [Note: ~400MB QuickTime movie about alternative web frameworks, including plone] of all these frameworks--gone! Rhino Igloo has some very, very interesting ideas reminiscent of Guice and Spring javaconfig in its used of an InjectAttribute. WCSF does this, too. Both of these require that the request is made to and handled by the view (the Page), and they use DI tricks to get the Controller involved. ASP.NET MVC is using an extensible URL rewrite feature to put the controller first. This lets us be RESTful in addition to being PF-friendly, e.g. we can handle requests with our controller.
Continuations
My major complaint with all of these frameworks is that don't let me writing applications in a natural way. I don't write my application in terms of logical processes, instead I implement page flows and deal with all the problems of stateless web applications. In the nine years that I have been building web applications, my view of what a web application is and should be have changed a lot. Now, I believe I have seen the promised land, as it were. Web application servers and frameworks should allow me to develop my applications with logical continuations and take care of the plumbing for me.
REST + Continuations + Presenter First = ?
So, REST is good because it provides clean, bookmark-able URLs, a sort of coherent web-based command-line. Continuations are good because they let me write applications that simply do not care that the next program event is dependent on transient sessions over a stateless protocol. The Presenter First pattern is good because its raison d'être is making MVP more amenable to test-driven development. Unfortunately, there are no ASP.NET web frameworks out there that take these three to be their cardinal virtues. So, we'll just have to go invent our own.
In a follow-up post to this one, I plan to introduce my prototype for just such a framework. Utilizing some of the functionality of ASP.NET MVC and Windows Workflow Foundation, along with a lot of new code and concepts, I am building a prototype that I hope proves to be a huge evolution in web programming on the ASP.NET platform.
