Simplicity does not precede complexity, but follows it. -Alan Perlis

I recently sat down to begin a new ASP.Net MVC project and although I am familiar with these tools, a strange sense of unease grew in me as I downloaded the following:

• Fluent nHibernate (persistence/orm)
• Automapper (model mapping)
• Ninject (IOC container)
• nUnit (unit testing)
• Moq (mocking/isolation)
• Spark (view engine)

Six distinct dependencies simply to make a good start on my project! Why does this feel unnecessarily complex? Is there something inherently wrong with our approach? If my goal is to provide a good user experience and solve business problems, why do I feel that I’m spending so much time with plumbing?

Part of this is attributable to the fact that C# is a statically typed language, and lacks the flexibility of dynamic languages like Python and Ruby. In order to write maintainable, testable code in a statically typed language there is some overhead complexity. C#’s syntax, like many statically typed languages, is unavoidably verbose. Consider this comparison of a roughly equivalent MVC.Net and Rails controller from Brian Hogan. You’ll notice that in addition to being terser, the Rails code also makes some sensible assumptions that reduce the weight of the controller.

Interestingly, none of the tools for the MVC project I mentioned above are provided by Microsoft. Although Microsoft provide analogues to some of these such as the Entity Framework, they have been late in coming to the party and the .Net community generally has little interest in their adoption; the open source projects are simply more mature. Many of these projects are artifacts of a community that has grown tired of Microsoft’s ambiguous noncommittal attitude towards best practice, and software design. In fact, an entire community has sprung up over the last several years, self dubbed Alt.Net, in an attempt to address the problem of Microsoft’s vague approach to their platform.

Flirting with Ruby

Over the last year, my time spent in the evenings with Ruby has coloured my perception of .Net development.

It is often better to be in chains than to be free. -Franz Kafka

If I understand Herr K correctly here, I think he was implying that restrictions can be liberating and help to preserve ones sanity, and this has been my somewhat paradoxical experience with Rails.

$rails niftyapp

With that seemingly magical invocation, Rails immediately provides you with:

• complete project directory structure
• simple, abstracted persistance
• foundations for functional, unit, integration and performance tests
• an integrated application server
• scripts for generation of models, controllers, tests

More importantly however, Rails provides you with direction. There is a clear and defined way of interacting with the framework. There is a Rails Way, and over time one becomes aware that there is also a Ruby Way (both titles of two popular books). Amusingly, a further paradox - while Rails is successful largely because of it’s prescriptive opinionated approach to development, Ruby is anything but restrictive. The creator of Ruby, Yukihiro “Matz” Matsumoto in fact cites Larry Wall as one of his heroes. The flexibility of Perl has transferred to Ruby, albeit in a somewhat more human and digestible form.

ASP.Net in stark contrast provides you with very little in the way of direction. In fact, Microsoft provide two web development frameworks - ASP.Net Webforms and ASP.Net MVC. Although MVC.Net is newer and clearly represents the model adopted by 90% of the world’s web development frameworks, Microsoft still remain noncommittal about which framework you should choose.

Correctly, Microsoft has not positioned ASP.NET MVC as a replacement for ASP.NET Web Forms. Web Forms is definitely a pattern that works for Web applications.

Dino Esposito on Comparing Web Forms with MVC (MSDN)

In terms of persistence, the story is further complicated - Microsoft offer ADO.Net Datasets, Linq2SQL and the Entity Framework.

Out of the box, Rails provides an Active Record implementation that makes concerns of persistence refreshingly easy. Schemas are defined in Ruby migrations instead of SQL. The Rails community is also making swift inroads towards NOSQL implementations. Tools such as MongoMapper allow persistence to become an almost non-existant concern with relatively little setup. After spending any time with a baroque .Net ORM this is astoundingly liberating.

I can only attribute Microsoft’s lack of a unified voice to the fact that their development teams operate in silos. There is certainly progressive work being done at Microsoft; Jimmy Schementi’s DLR team is a testament to this, yet we see another version of Visual Studio ship without IronPython support.

Microsoft need to provide better guidance to a community that is increasingly finding their needs better met by OSS offerings. The Rails philosophy of convention over configuration has obviously resonated with developers, many of them in the Microsoft camp. ASP.Net MVC is an excellent foundation for an opinionated .Net web development framework, but in its current state creates more questions for developers than it answers. Rails 3 with its Merb influenced modularity provides the flexibility that proponents of un-opinionated frameworks desire, while maintaining it’s integrity and structure in a default configuration. MVC.Net however provides a treacherous sea of possibility that only the most experienced developers can navigate successfully.

One can’t help but feel that MS is simply too large or possibly too divided to crystalise and focus their approach to their platform. When some of the most visible proponents of the Alt.Net community express that the only reason they continue developing for the .Net platform is a paycheck, that to my mind is cause for Microsoft to sit up and take notice.