Menu

Subscribe

ASP.NET MVC: An Application Platform

on mvc, asp_net, asp_net_mvc

The MVC / WebForms Debate

Yesterday I wrote about the stored procedure/dynamic sql debate - I must be feeling a bit argumentative lately, because today I was reading post on WebForms versus MVC

“The best advice I’ve seen so far is that WebForms is the platform of choice for building web applications, where MVC is more suited to building web sites.  This is still a bit abstract since there’s no clear definition of web applications, but I think it’s safe to say that if you’re building a web version of a win client application, you’re building a web application.  If you have a ‘grid’ in your page for purposes above that of just layout, you’re building a web application.”

It’s true is very attractive for “web sites” when you consider how nicely url routing helps you build an SEO friendly site that also adheres to RESTful

MVC as an Application Platform

I agree with your argument to use the best tool for the job. This is always the case in software development and loosing site of this is just going to bite you in the end. However, I believe that as future versions continue to be released WebForms

MVC is an application platform from the ground up. There are many reasons why, here are some that matter to me:

Model Binding

When WebForms was first released I was so excited that I didn’t have to use and (or just plain ) to get access to my form data. I could look at a or better yet a and get not only the value submitted via POST but I could inspect additional properties like .Text. It was a much richer model than classic ASP

What this new model didn’t do for me was return primitive

I have been using MVC since Preview 1 (Nov 2007) and I have found that it gets out of my way. I get strongly typed binding both in my view and when responding to any request. I no longer have to spend time parsing strings into primitive types then hydrating an object by hand. Instead I just have to do this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Mvc.Ajax;
namespace MyApp.Web.Controllers
{
 public class MyObject {
 DateTime Date { get; set; }
 Int64 Integer { get; set; }
 String Text { get; set; }
 }
 public class Default1Controller : Controller
 {
 [AcceptVerbs(HttpVerbs.Get)]
 public ActionResult Index() {
 return View();
 }
 [AcceptVerbs(HttpVerbs.Post)]
 public ActionResult Index(MyObject model) {
 // save my model
 Repository.Save(model);
 return View();
 }
 }
}

I think that speaks for itself.

RAD Without Drag-n-Drop

It’s no secret you get no DnD from MVC. But here’s what you do (or will) get:

  • Scaffolding – at the moment this is a bit of a stretch to say MVC gives you scaffolding

image

  • Easy HttpHandlers – need to return an image or file other an an HTML response? The WebForms way is usually to create a Generic Handler (a class inheriting from ). You can do it with System.Web.UI.Page
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Mvc.Ajax;
namespace MyApp.Web.Controllers
{
 public class Default1Controller : Controller
 {
 //
 // GET: /Default1/
 public FileResult SomeFile()
 {
 return File("/Path/To/File.ext", "content/type");
 }
 public JsonResult JavaScriptObject() {
 return Json(new { 
 Property1 = "something", 
 Propety2 = DateTime.Now, 
 Property3 = 323.00 
 });
 }
 public JavaScriptResult ClientScript() {
 return this.JavaScript("function message(val) { alert(val); }");
 }
 public PartialViewResult HtmlSnippet() {
 return PartialView("NameOfAscxControl.ascx");
 }
 }
}
  • Lightweight Web Services – as a side effect of easy control over the mime-type of your results you can create your own lightweight web services without the need of formally creating web services via .asmx or .svc files. allows you to make easy calls from your javascript and return a resonse or use and specify application/xml as your content type and you’re off and running with a working response to an ajax

Testability

If I’m building an application then being able to write unit tests for both my application logic and business logic is very important to the long-term life of my project. Applications are organic, they change and grow in size and complexity. Often an application will outlive the employment of the programmer(s) who wrote it. Maintaining unit tests ensure that the application continues to work as intended. This keeps things clean and maintainable, which in turn extends the life of your application longer than any other method I know of.

Control

WebForms is very closed when compared to MVC. Sure you get a lot of control/flexibility through HttpModules

Other Concerns

WebForms Designer vs. Raw HTML

Many people site having to get their hands dirty in html and how nicely WebForms abstracts these details from them. This is strictly my own opinion and I may be biased. I started out almost 10 years ago writing HTML and classic ASP in notepad and I have never used the WebForms designer. I’ve tried it many times, but I find that it slows me down and very quickly looses any fidelity with the end result such that it becomes worthless to me.

Writing server controls by hand and writing raw HTML by hand are almost the same – it’s all tag soup. In some cases I’d even rather write the raw HTML when you compare the two:

compared to:

But even there I get helpers:

<%=Html.TextBox("myTextBox")%>

Tag Soup?

On a related note: after years of WebForms we’ve become conditioned to believe that the classic ASP style escapes (<%= %>)are bad, bad, bad. It’s mixing server code with markup. How’s that different from a server control – it isn’t html either, it just looks like it.

What’s bad is placing logic into the page. Rob Conrey

Conclusion

Should you evaluate the needs of your application against the benefits of WebForms vs MVC? Yes. Should you learn MVC so you know what it has to offer? Most definitely. Will you regret using MVC? I haven’t and I don’t believe you will. MVC is an incredible application platform and it will only get better. WebForms was developed in a relatively closed way, whereas from day one MVC was developed with extensive community involvement and feedback. It had 5 preview releases before beta and was being used in production environments all along the way. The MVC team developed this so that it works and it works well. Give it a spin, you won’t regret it.