Initial thoughts on ASP.NET MVC

This blog entry is entirely abstract, no code whatsoever.  And it contains opinion.  If opinion offends you, or if you only want functional code to play with, this entry will probably just frustrate you. That said, my topic of discussion is the new MVC option for ASP.NET.

The Model View Controller Framework: Brought to You by Microsoft

Well, Microsoft has an official Model / View / Controller add-on available for ASP.NET. This might not be news to you. And, I venture to say that most people who use it will be coming from a previous iteration of ASP.NET and not really know much of Ruby on Rails, or Django (the open source MVC architectures). I went ahead and took the plunge and did the test drive of ASP.NET MVC just to see what I thought, and here are my initial feelings.

My first thought is that the Microsoft MVC is much more like Rails than it is like Django. The URL is parsed for you into /Controller/Action/id, of course, you could override it (in true rails fashion) the default is built for you (unlike Django). It also has controller classes (like Rails) which have functions for each Action.

What ASP.NET MVC lacks is the Rails “Magic”. Honestly I am not a fan of Rails Magic, I prefer Django’s philosophy that magic should not be what makes everything work. The magic I am talking about actually runs deeper than you might think. Rails and Django are written in so called “scripting languages”. In scripting languages, objects are very fluid, objects can define themselves at run time rather than having strict classes built at compile time. The effect that this has is two-fold. (1) a lot of rails magic isn’t even possible, such as defining database relationships in the model using odd functions in the class definition such as HasAndBelongsToMany, or creating functions that are called before the actions in a class (actions seem to be called directly by the framework). Also, you must explicitly return a View object in an action, even if you just want the view by the same name as the action to be returned. (2) You get early binding instead of late binding. This means you get compile time warnings about calling functions or accessing data members that don’t exist. It also means you get compile time decisions about which overloaded functions to call as opposed to run time object evaluation. This means it is capable of being much faster.

In Rails and Django, it’s the base classes provided by the model that make application development so powerful. The ActiveRecord and Django.Model classes are the beginning of development for an MVC app in either of those two languages. In Django, I usually start building an app by pulling up models.py and defining my data. It gives me a single file that lets me define all the fields and relationships in my data model. The framework uses that to produce the actual tables and SQL necessary to finish the task. When you are done, the “model” layer includes all the data related stuff, and will also contain the validation information that you want controlled at the database level. In Django, the model is the starting point. When you want to add features, you start with the model and work out from there.

Rails is another animal altogether. You start with an update file, you create or modify each table by creating an update function (and corresponding downgrade function). These functions use ActiveRecord to keep things database neutral, but the end result is that the database is defined by the result of the update functions, and not really defined by classes with properties representing the database fields. The actual classes that represent records in the database are generated magically at runtime (hurray for scripting languages) and the files that define the classes only really contain information about relationships between different tables and other code that cant be generated on the fly by accepting the default implementation for everything. To be totally honest, I hate this method of doing things. It makes it terribly difficult to just print off something that lets you see your database structure and pick it all apart. The things that define your model are divided up into hundreds of little files, none of which tell enough of the story to be truly helpful, but all of which contain enough that they can’t be ignored. The only thing easy about the way Rails defines its model is the upgrade (and downgrade) path for your schema is significantly easier to walk than the upgrade path in Django (or ASP.NET MVC).

Microsoft’s way is a bit more like Django, with a Microsoft centered twist. Instead of defining the data classes in code and generating the DB creation scripts, you define the database in whatever database engine you intend to use, and then generate the classes to match using LINQ. This approach is the way .NET has always treated databases, and has the effect of making it hard(er) to switch to a new DB engine. You can see the repercussions of this: SQL Server Express ships free with Visual Studio Express (also free), and by default, people will use SQL Server. Once you generate your model classes and start building on top of them … your hooked. To be totally honest though, who cares.

Everyone seems to agree that model/view/controller is a decent design pattern and makes for easier web application development. But, no one seems to agree on what belongs in each section of the app. For instance, in Rails, the “Model” is largely generated by the database, and has nothing but database interaction code in it. The View files are all used to generate a page viewable in the browser. All the extra fluff (like business logic) is in the Controller layer. In Django, the Model defines the data, and contains very little more than table and field names. It could be used to enforce business logic, or not – you decide, its your app. The controller is really the Django framework itself, along with a few things you define, which are usually settings, not code. So, the View contains all the page handling logic, as well as forms validation etc.

So how does Microsoft split things up? The controller layer is for web page routing and forms validation (similar to Rails). The View layer contains aspx pages (again similar to rails), and the Model contains EVERYTHING else (business logic, LINQ classes, or some other database interaction code of your choice). The tutorial I went through even said that if the controller classes have action functions that start getting to be more than a few lines long you should consider moving that logic into a function that is stored in the model layer somewhere.

The model is the fundamental difference between ASP.NET MVC and previously existing MVC web frameworks. For Rails and Django, the model is what makes each one distinct and powerful. The model gets to focus of the development attention. The elegant design of the model is what is so darned attractive. In ASP.NET the “model” is left for you to define. Now, just because it is left very open ended, that doesn’t mean it is really a cop out. In fact, it seems that the addition of LINQ to the .NET framework is intended to be the model language for ASP.NET MVC. So, it isn’t like they gave you nothing to work with, it is just a much fuzzier line than what I expected coming from a Rails/Django background.

The other fundamental difference I see is the complete lack of scaffolding. There are some scaffold generators out there, and there seems to be a plug in or something in the works, but honestly, day one in Rails you learn to use scaffolding – it’s the first big “wow, that rocks” experience you get when developing in Rails. With Django, the built in admin pages have the same effect (if not significantly more so). Lack of scaffolding left my tour of the Microsoft MVC feeling a bit under-whelmed.

The other thing worth noting is that you loose a lot of what makes ASP.NET so productive.  In ASP.NET, the page is central.  All the logic for a page is contained on that page.  You have instant Ajax without even knowing it by using an <asp:textbox> tag with scripts that run on the server.  All the magic is generated for you to pass things back and forth between the logic defined in the page and actions on the client end.   This can’t be magically done for you when the processing center of the page is now a controller class that uses pages like functions instead of fully fledged independant applications.  You have to handle your post-backs manually.  Not that difficult, but it is a step backward (at least in that particular direction) from doing things the normal ASP.NET way.  My hope is that ASP.NET MVC will get to be so popular, and enough people will harp on this shortcomming that it will be fixed — or a suitable alternative for forms processing will be provided.  Currently I dont see a conveneint “form” base class that lets me generate and validate forms the way Django does, and I dont see the built in Ajax functions that makes Rails easy to use dispite the fact that you have to handle it all in the controller.   Forms processing is sort of underbaked.

This is a preliminary judgment of the new framework, and overall, I am excited to start using it. It seems good. As a semi-compiled language with early-binding, it has potential to be much faster than rails (time will tell). It does have the effect of organizing the code so that designers can work on the view, application programmers can work in the controller and systems architects can focus on the model without getting in each other’s way. I’m reasonably impressed. I think it’s a step forward. I think LINQ is better than ActiveRecord, but I doubt it will be as nice as Django Models. I guess only time will tell.

The other thing I want to see is whether or not the fanboys who author the books published by Microsoft Press will completely ignore the fact that MVC was first popularized by Ruby on Rails, and the ASP.NET MVC framework is obviously designed using Rails as the primary reference for how to do it right. Will Microsoft’s propaganda act as though they invented the idea, like everything else that comes out of Microsoft?

More importantly, I wonder if, like other things, Microsoft will learn from the other guys, and then go on to make something significantly more usable. Maybe in a couple of more major releases of the .NET framework, will ASP.NET MVC be truly superior? I bet it will.

Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.

Comments

No comments yet.

Leave a comment

(required)

(required)