Simon Torkumine, a Ruby on Rails developer, recently blogged about how the ASP.NET MVC framework compares to Ruby on Rails. While there are some parts of his post that I don't necessarily agree with (e.g. the anemic community, C# being too verbose), one point he brought up rang true to me:
.NET MVC is actually .NET VC. It is an attempt to replicate the Actionpack components of Rails. There is nothing included aside from a folder labeled “Models” to help you with your persistence later and domain modeling. As others have mentioned, there are other ORM tools out there, but bear in mind these are targeted at traditional ASP.NET development and are not integrated into the framework as in other MVC’s. This means that you’ll be writing your own validation and form handling code for starters.
I couldn't agree more. The biggest pain point in my development experience with the ASP.NET MVC framework has been its incredibly lax approach to the "M" in "MVC". Whereas the views and controllers are pretty much hashed out, developers are essentially thrown into the deep end when it comes to the model. That means that persistence and validation is completely up to us, which is great for experienced developers who have very opinionated views on what best to insert here but extremely terrifying when for developers approaching the framework for the very first time.
This may be a matter of opinion here, but for me web application frameworks are expected to come with all the necessities to get a basic site up and running. This is not so when it comes to the ASP.NET MVC framework. At first it appeared that Linq 2 Sql would be the clear-cut answer to the persistence question. After all, Linq 2 Sql was developed by Microsoft and was used in almost every single Microsoft blogger's posts on ASP.NET MVC. But then something happened. Microsoft announced that it would no longer be supporting Linq 2 Sql and ever since then the community has been a flock without a sheppard.
Microsoft's suggested replacement, the Entity Framework, is so actively despised by the community that there was a petition against it. To date, I have yet to see a single example of integrating the Entity Framework into an ASP.NET MVC application. NHibernate has a decent following, but it's not exactly user friendly or easy to set up. Subsonic, the obvious alternative to Linq 2 Sql doesn't appear to have garnered too much support.
Validation has also gone by the wayside because of this as it is tends to be tied in with the persistence layer. Scott Guthrie's initial post on validation in the ASP.NET MVC framework revolved around handling Linq 2 Sql's "OnValidate" event when saving off entities to the database. Now that Linq 2 Sql is essentially out of the picture, we're left with either writing our own or going with one of the many newly created OSS solutions like xVal.
There is a significant difference between being allowed to go outside the box and being forced to. The "rails way or the highway" approach that Ruby on Rails takes is great for beginners, but not so great when you want to go outside of the box. ASP.NET MVC's complete lack of guidance when it comes to models has the opposite problem in that beginners don't know what to do, but are free to explore whatever options they want. This may prove to be a big problem for the adoption rate of ASP.NET MVC now that it's advancing past the point of early adopters who are willing to put up with the growing pains.
To be clear here: I know that there are several valid solutions for how to handle validation and persistence in ASP.NET MVC, and it's great that each of them is available to us. The problem is that you have to actively hunt these solutions down instead of having one of them baked into the framework. It's great that ASP.NET MVC is so extensible that you can essentially plug in whatever you want, but at some point some basic guidance is called for. A blank slate is intimidating and not very user friendly.
In the end, it seems like there should be a middle ground between the Ruby on Rails approach and the ASP.NET MVC approach. Perhaps the project template could ask the user if they wanted to link this application up to an existing database or create a new one? If they did, it could generate the model (even if it were empty) using Linq 2 Sql and throw in Scott Guthrie's validation code in there as well? That would provide users with a starting point at least that could be easily ignored or stripped out if so desired.
What are your thoughts? I want as much as anyone else to see ASP.NET MVC become successful — and in my opinion it could be — and it would be a shame to see if struggle in the wild because it didn't take a few extra steps to cater to the beginner audience.