For those that haven’t yet tried out the world of MVC, this post was intended to give you my take on it, comparing and contrasting where possible, and to the best of my knowledge. (Don’t shoot me if I’m wrong, I’m still learning about it too!)
If you look at the documentation from Microsoft, ASP .Net MVC is built upon the ASP .Net stack, meaning that it isn’t meant to reside alongside the Win-Forms route, but in addition to it, so don’t think that this *has* to replace the Win-Forms approach, as there’s probably a reason to use one over the other.
Some key points:
-
ASP .Net MVC is still a platform to make web-based applications
-
HTML pages are still produced, that use CSS for styling
-
You can still work in either VB .Net or C#
-
It still compiles in the same manner
-
and you can achieve the same results (almost), but the way that it happens is different.
Having said that, there are a few differences between them, and it’s these differences, for me, that make me want to learn to use MVC a little more-so than.
-
MVC doesn’t use ViewState and therefore is stateless
-
MVC encourages cleaner URLs
-
MVC encourages better separation of concerns
-
MVC attempts cleaner output HTML markup
-
MVC encourages the ‘Convention Over Configuration’ theory
-
MVC discourages the code-behind element
In terms of the lack of ViewState, this isn’t a bad thing; the output HTML markup is much cleaner as the ViewState doesn’t get added to the page.
The cleaner URLs are almost like a bi-product of the separation of the code out between the Models and the Controllers; what I mean here, is that by grouping pages (now called Views) into subfolders and having a dedicated controller for each subfolder, the URLs within the address bar of the browser look more like:
http://whatever.com/Accounts/Create
which means that search engines, such as Bing, Google, etc can spider and categorise the pages better, if so desired.
Also, notice that the Create page doesn’t have an extension on it by default. This is due to the routing engine of MVC, as page-requests from the browser no longer go direct to the .aspx pages as before in ASP .Net. Instead, page-requests are sent to the associated controller, which then produces the requested page as a result and returns it back to the browser. So, in actual fact, in the example link above, the ‘Create’ method, or ActionResult as they’re now titled, is called within the AccountsController object. Being a regular piece of C#/VB.Net code, this method can call-out to the data layer and bring back the necessary information to produce that page alone, resulting in a return statement, producing the page.
Why is this better? This approach helps to make the Controller handle any sort of business logic, and help keep the View page dumb, displaying only what it’s passed to, by it’s controller.
The way that the data is passed to the page is significant also, as objects from the Model can be used, meaning that you can create and populate fully-fledged Person object and pass it to the View like this:
return View(myPerson);
and within the markup of that page, you can access any property of the Person object like this:
<div>
<p>Your name is <%=Html.Encode(Model.Firstname) %></p>
</div>
And yes, I know what you’re going to say about the <% %> syntax, and it’s similarity to the good ol’ Classic ASP days, but you have to see past this and reap the benefits that it brings. It does mean that the HTML markup has lots of <% %> markers in it, but this will only get as messy as you make it. I forget who said about the fact that “developers make spaghetti code”, meaning that your code is your fault when it looks a state.
Busy pages can be refactored out into Partial Views, allowing their use by multiple other pages, as well as promoting adherence to the DRY principle (“Don’t Repeat Yourself”).
In terms of further separating out the business and/or data layers to their own projects, this is still acceptable, but it’s worth pointing out that the vast majority of MVC examples that I’ve seen so far, throw all layers of a site into the same Visual Studio project, probably for ease of display.
Getting started with MVC is easy once you have downloaded and installed the small Visual Studio plug-in, as it’s literally:
File > New > ASP .Net MVC Project
By default, the new MVC project has a few pages as well as a fully operational log-in/registration area for a members area of the site. So, right after creating the project, you can run it and click between the dummy pages that exist to demo it’s early stage.
This gives you, as a developer, a starting point to learn from as in order for this [albeit basic] functionality to work, it must have the necessary Controllers, Views, etc in place. Also, when creating a new project, having a visual starting point is also good, as the default CSS file ensures that the environment is already there to start work from, but can be totally changed later.
I mentioned about the Convention over Configuration that MVC has taken on, and to start with, I was fully aware of how wide this reaches within the project. What Convention over Configuration means, is that, for example, the controllers all have to end with ‘Controller’, so you’d have AccountsController, HomeController, SomethingElseController, etc. Then, when the Views are generated by Visual Studio for you, they use whatever is before the …Controller part as the folder names, such as Accounts, Home, SomethingElse, etc. Because the whole process assumes that everything works to the same convention, things ‘just work’ on that basis. Like almost everything else in MVC, you can override this behaviour, but once you’ve made a cock=up or two doing it, you probably won’t forget it, and even come to liking this way of working, rather than having to specify details of things in .config files.
Personally, I’m a fan of this whole MVC thing. I’ve been playing around with MVC 1.0 which came out a while ago, but also been using MVC 2.0 which is not released until 2010. Some of the improvements to 2.0, such as the Data Annotation Validators, are great and
I learn new things like this best when I’m actually working on something constructive, rather than just playing around with dummy (pointless) apps, so I’ve been making a CRM application in MVC (1.0) and, bearing in mind I knew nothing about MVC before I started, it’s not too bad. One thing I will admit, looking back at the work I’ve done earlier on in the project, I see big areas that I now want to refactor after learning the better way of doing things in ‘MVC-land’.
That’s not to say that I’ve done it particularly wrong or badly, but there is a cleaner path to the same outcome that can be achieved, if I want to go back an re-work it. I think that at the time, there was quite a bit of difference to what I was used to, and probably more that I was a little too eager to get something down in code. Either way, I’m happy that what I’ve done so far is ‘ok’, but I know the next project that I’m already working on is already better because of the first.
But as to what technology to use for your next project, that’s entirely up to you, but I know what I’d like to use.