Why I Use ASP.NET MVC
I used to do a lot of web development. These days I do rather less of it - I'm far
more involved with architecture and teaching - but most of the systems I'm
involved with have a web frontend, so I keep a very keen eye on the technologies
that are available. Additionally, I often end up building small tools that need
some kind of interface, and I'd much rather whip up a web one than mess with
desktop apps. Many development shops in Sweden work with .Net, and these days
often choose between Web Forms and MVC. I suspect the title of this post gives
you a good idea of my preference. :-)
Embracing the web
Good technologies often embrace the way the thing they're built on actually
works. Take jQuery. It doesn't try and fight JavaScript having prototype based
OO by fudging a class system on it, as various efforts to tame JavaScript did.
Instead, it embraces it - and the results are pretty nice.
ASP.NET Web Forms suffers from a certain amount of fudgery: it tries to hide the
stateless nature of the web by saving state for you. The result is view state
(which bulks up pages) and mangled field names (which make client side development
a little more painful). Trouble is, the stateless nature of the web matters; it's
an important part of why it has scaled so well.
ASP.NET MVC embraces the way the web works, and focuses on allowing you to work
efficiently within that. There's no view state. The HTML you write is the HTML
you get. IDs don't get mangled. ASP.NET Ajax is mostly dropped in favor of jQuery
(by now something of a de facto standard).
A better factoring
To be fair, Web Forms did bring huge advantages over classic ASP when it arrived.
It put an end to mixing up logic and HTML in a single file, separating them logic
out into a codebehind file. Unfortunatley, the factoring hasn't really stood the
test of time. These days, developers are more interested than ever in writing
tests, and dependency inversion often shows up with this desire. Web Forms isn't
too friendly to either of these goals.
MVC makes a three way division. HTML goes into the view, which is rendered by a
view engine. There are no controls like in Web Forms; there are, however, helpers
for generating various pieces of HTML. The data that the view is to render is
supplied in the model. The model is just some .Net object. There are no constraints
on what this object can be, so you can do anything from using entities from Entity
Framework (which usually is a bad idea, mind) to a command object being built up
in a CQRS based system.
The interesting logic lives in the controller. In ASP.NET MVC, a controller is a
class that inherits from the Controller base class, and contains methods that
are known as actions. Each time a request is made, it is routed to the applicable
action method. This method builds the model and selects the view - thus it is in
overall control of the request's processing.
Why is this more testable?
The controller is a normal class. You can make an instance of it in your test, call
the action methods (since they are just normal methods) and look at the return value,
which in turns lets you get at the model that the controller built. Essentially, it
is a lot like writing tests against any other class in .Net; you can use whatever test
tools you are familiar with.
And what of dependency inversion? The MVC framework provides a hook for you to integrate
a DI container of your choice, such as StructureMap. In fact, for some of them there are
even NuGet packages to do the wiring up for you.
What's coming up?
ASP.NET MVC is very actively developed and has frequent releases. Version 3 didn't come
out all that long ago, and yet version 4 is already in beta! Perhaps most exciting is
that it will bring Web API, a way to implement REST-based web services. It looks rather
more convenient than WCF for this kind of task, and the factoring will feel familiar to
anybody who is already used to working with ASP.NET MVC - it's just a different type of
controller!
Learning More
I teach a 2 day getting started with ASP.NET MVC 3 course for Informator. At the moment,
I'm working on updating it to cover ASP.NET MVC 4; it will also be extended to a three
day course to allow this, but also to enable me to go into much more depth on testing. Also,
we're planning the next Community Day, and I expect to be giving a talk on Web API.
/Jonathan Worthington
I used to do a lot of web development. These days I do rather less of it - I'm far
more involved with architecture and teaching - but most of the systems I'm
involved with have a web frontend, so I keep a very keen eye on the technologies
that are available. Additionally, I often end up building small tools that need
some kind of interface, and I'd much rather whip up a web one than mess with
desktop apps. Many development shops in Sweden work with .Net, and these days
often choose between Web Forms and MVC. I suspect the title of this post gives
you a good idea of my preference. :-)
Embracing the web
Good technologies often embrace the way the thing they're built on actually
works. Take jQuery. It doesn't try and fight JavaScript having prototype based
OO by fudging a class system on it, as various efforts to tame JavaScript did.
Instead, it embraces it - and the results are pretty nice.
ASP.NET Web Forms suffers from a certain amount of fudgery: it tries to hide the
stateless nature of the web by saving state for you. The result is view state
(which bulks up pages) and mangled field names (which make client side development
a little more painful). Trouble is, the stateless nature of the web matters; it's
an important part of why it has scaled so well.
ASP.NET MVC embraces the way the web works, and focuses on allowing you to work
efficiently within that. There's no view state. The HTML you write is the HTML
you get. IDs don't get mangled. ASP.NET Ajax is mostly dropped in favor of jQuery
(by now something of a de facto standard).
A better factoring
To be fair, Web Forms did bring huge advantages over classic ASP when it arrived.
It put an end to mixing up logic and HTML in a single file, separating them logic
out into a codebehind file. Unfortunatley, the factoring hasn't really stood the
test of time. These days, developers are more interested than ever in writing
tests, and dependency inversion often shows up with this desire. Web Forms isn't
too friendly to either of these goals.
MVC makes a three way division. HTML goes into the view, which is rendered by a
view engine. There are no controls like in Web Forms; there are, however, helpers
for generating various pieces of HTML. The data that the view is to render is
supplied in the model. The model is just some .Net object. There are no constraints
on what this object can be, so you can do anything from using entities from Entity
Framework (which usually is a bad idea, mind) to a command object being built up
in a CQRS based system.
The interesting logic lives in the controller. In ASP.NET MVC, a controller is a
class that inherits from the Controller base class, and contains methods that
are known as actions. Each time a request is made, it is routed to the applicable
action method. This method builds the model and selects the view - thus it is in
overall control of the request's processing.
Why is this more testable?
The controller is a normal class. You can make an instance of it in your test, call
the action methods (since they are just normal methods) and look at the return value,
which in turns lets you get at the model that the controller built. Essentially, it
is a lot like writing tests against any other class in .Net; you can use whatever test
tools you are familiar with.
And what of dependency inversion? The MVC framework provides a hook for you to integrate
a DI container of your choice, such as StructureMap. In fact, for some of them there are
even NuGet packages to do the wiring up for you.
What's coming up?
ASP.NET MVC is very actively developed and has frequent releases. Version 3 didn't come
out all that long ago, and yet version 4 is already in beta! Perhaps most exciting is
that it will bring Web API, a way to implement REST-based web services. It looks rather
more convenient than WCF for this kind of task, and the factoring will feel familiar to
anybody who is already used to working with ASP.NET MVC - it's just a different type of
controller!
Learning More
I teach a 2 day getting started with ASP.NET MVC 3 course for Informator. At the moment,
I'm working on updating it to cover ASP.NET MVC 4; it will also be extended to a three
day course to allow this, but also to enable me to go into much more depth on testing. Also,
we're planning the next Community Day, and I expect to be giving a talk on Web API.
/Jonathan Worthington
