Welcome back, it’s now time for part 3 of this tutorial. In the previous part of this tutorial we had just created an empty database on our SQL Server and now we need to decide what kind of application should we create.

Well, I could think of many different scenarios but for this we’re going to try and create a basic support request logging and tracking application. First of all we’ll need a basic specification, which of course may change over time, as these things tend to…

  1. A form for users to enter or edit their support request details
  2. Some kind of list so users can see their support requests and admins can see what is being logged

One thing to note is that for this application, since we’re using Windows authentication we don’t need to setup any login forms or user/account tables. If we were using other kinds of authentication then possibly we would need to. For now we’ll start simple…

All well and good but how does all translate into an MVC app, and what is this MVC anyway, why should I use it?

Good question (and bear with me for those who already understand the concept of MVC), the MVC design methodology refers to Model, View, Controller. What?

If you’re after a more in depth explanation then Martin Fowler has written a section on MVC here for anyone interested. For our purposes here and now I’ll give a basic explanation of what it is, how the design pattern is implemented in Microsoft’s ASP.NET MVC framework, why you should (probably) use it and also when.

In classic (and most current) web applications you have communication taking place between a client machine (usually via a browser) and a web server such as IIS or Apache etc… On the client machine a user for example would enter an address into their browser’s address bar and the browser will then ‘ask’ the web server for a response. The server then builds the appropriate response, sends it back to the client and the browser then parses the response and usually renders something visible on screen which the user can see as the requested web page.

So, imagine you’re creating an account on some site, you’ll enter your details into some kind of form then submit this form and then hopefully you’ll get an account created for you. In MVC this process is split up into sections so that we have a nice clean separation of concerns which is to say that each part of the process is only concerned with what it needs to do. This is unlike is classic web programming (such as web forms) where all these sections are mixed up together. This breeds complexity and makes it very hard to test, debug and trace errors. If you think about this for a while it should make perfect sense really and could (and probably should) be applied to many other areas of computing. Using this separation of concerns we end up having code that only worries about rendering something on screen, code that only manages or describes the data and finally code that handles the interactions between the other two. So in other words:-

  1. Model – this would be for example a simple class which describes a user account. Generally people will tend to model a real world thing or entity as a single class. It can get more complex but on the whole…
  2. View – this knows only the structure of the model, but not how to create one or manage it. The view only knows that it can get certain data from the model which it can display in whatever style or format is required
  3. Controller – this handles incoming requests (from the client usually) and decides what to then do next. Quite often this might also involve asking some kind of service to do something such as create an account. It then would usually send a model or models to a view

Modern web applications are particularly suited to this design pattern, which I guess is why MVC (not just Microsoft’s implementation) tends to be one of the most popular design patterns used in web design.

So, in the context of our little web application we would have:-

  1. Model – this will be a user account
  2. View – this will be a simple form for a user to complete to get their account details
  3. Controller – this will first send a blank form to the clients browser for them to complete and then will receive back a submitted form

Ok, I’ll leave things there for this post, I’m hungry, stay tuned for the next part…