For those unfamiliar with MVC, MVC stands for Model View Controller. It’s a way of separating the logic (controller), from the gui (view), and the data (model). The model contains all data needed by the view, the view shows it, and if an action occurs, passes the action to the controller, which does the logic, and updates the model again, so the view can be refreshed. The advantage of this is that, even though it ends up with more code, the code is a lot more readable, as the code needed for the gui isn’t mixed up with the logic needed for validation and the data isn’t in the view, but separated from the view, which just has a copy, it’s also a lot easier to reuse code to write a new view (for example, a web interface and a windows forms interface on the same data) as it’s not so tightly bound together.

Recently I’ve been looking at MVC frameworks for ASP.NET to improve code quality and ease of adding features. I have looked at both MonoRail and the MVC extensions for ASP.NET. And decided that even though it’s beta, the official MVC extensions for ASP.NET is the way to go.

The ASP.NET MVC extensions come with templates for C# and VB, and although we are going to provide templates for it in Chrome, we can’t do that till it’s finalized; these extensions change quite a bit between releases. But the project is fairly simple, it’s a Web Application Project, a standalone Class Library with a ProjectTypeGuid for ASP.NET, output directory for both profiles set to Bin/. Copying the web.config file, and using the same directory structure. The MVC logic uses a directory structure like:

  • Content (Folder containing anything you want to provide directly to the user, like css and images) - Site.css (Default Css style for the project)
  • Controllers (Folder containing the source code for the controllers) - HomeController.pas
  • Model (Data classes for the project)
  • View (directory containing all the views) - Home (view for the “Home” controller) - Index.aspx (asp.net page for the “Index” action)
  • Index.aspx.pas (code behind for the index action; descends from System.Web.Mvc.ViewPage)
  • About.aspx (asp.net page for the “About” action)
  • About.aspx.pas (code behind for the about action; descends from System.Web.Mvc.ViewPage)
  • Shared (view for the master page) - Site.Master (master page for the project)
  • Site.Master.Pas (code behind class for the master page, descends from System.Web.Mvc.ViewMasterPage)
  • Default.aspx (dummy page to redir to the action page)
  • Global.asax (application initialization)
  • Global.asax.pas (application initialization; sets up the mapping from /Controller/Action to the actual controller and view

As a project to play with this new framework I decided to tackle the long-standing issue for a web interface for our bug databases (we use a combination of MantisBT and a custom application using Data Abstract). We already had a simple login-da service for these databases, so the only thing needed was the actual web interface for it. Writing something using MVC takes practice, but it’s not hard; using a Remote Data Adapter to grab the data from the server; storing it in a List to pass to the view for the issue index. Another model was used for the per-issue listing. The view was kept as simple as possible, to just show the data.

Combining the power of ASP.NET, MVC, Chrome and Data Abstract, writing a web interface for the bugdb was a simple task. The web gui still needs some finishing touches to make it look good, but the coding is done, so the new bug db gui should be available soon.