In my previous post we setup our solution. We got the main ASP.NET MVC project created as well as our testing project and we left it in a state to begin coding.

 

In this post however, I’m going to go over what MVC is and the directory structure of the MVC web project.

 

So what is MVC?

MVC is simply a design pattern, the three letters stands for Model View Controller. The MVC pattern tries to address the need to keep concerns separated, as the name suggests, into three pieces, the Model, the View and the Controllers.

 

The Model

The Model is simply your Domain, Business objects, Application Services (the classes that do stuff to your domain, but doesn’t have a place in a single domain object) and it also encompasses your Data Access Layer.

 

The Controllers

The Controllers are classes that contain actions, these actions are synonymous with actions of your website, for example, Your Account controller might have a login action that takes a username and password which would then log someone into the website. The Controllers sit between the view and model, asking questions and issuing orders to the model, and converting information from the model into information that view can use.

 

The Views

The Views are the code and HTML to turn the data passed from the controller into the HTML the browser gets, these are generally dumb and should contain no business logic within them.

 

The ASP.NET MVC Project Structure

As you can see, the ASP.NET MVC project structure contains some similarities with standard ASP.NET Web Application structure. We have the Properties section, which holds the typical AssemblyInfo.cs. We have the App_Data folder which would hold your SQL Express data files. We also have a few others.

 

Content

This folder should hold the pure content parts of your site, in typical usage this would your style sheets and images.

 

Controllers

This folder should hold all your controllers.

 

Models

This folder holds the classes that make up your model. However this only really works if your model is small, most people will separate the model into it’s own assembly, as I will once I begin work on it.

 

Scripts

This folder should hold your client side scripts, such as Javascript scripts and libraries. You’ll find it comes pre-populated with Microsoft Ajax and JQuery.

 

Views

This folder will hold your views, normally sub-foldered into folders with the name of the controller that the views apply to. There is also often a Shared folder that would contain View specific items that are shared between everything, for example, controls and master pages.

 

The views folder also has it’s own Web.config, this is supposed to be there, as it configures some things (mainly validation related things) that should only be applied to your Views.

 

Files in Root

You’ll also notice we have a Default.aspx file in our root structure. This palms off any requests that make it to this page to the MVC handler, this shouldn’t need to be changed.

 

Global.asax contains (by default) the code to register the routes in our application. (More on routes in a later post)

 

And there is also a Web.config which is the main configuration file for the application and would be where you place any application configuration into.

 

Short and sweet, the end to another article

So there you have it, an explanation on MVC and the ASP.NET MVC structure. In the next article, we will get to write our first line of code. I promise.

In part 1 I laid out the requirements of the application and went over a simple design for the basics of the application.

In this part I’m going to go over setting up the project ready to begin coding.

Installing ASP.NET MVC

If you haven’t done so all ready, you will need to install ASP.NET MVC, which the installer can be found here.

As you can tell, I’m using version 1.0 as 2.0 is still in pre-RTM state. Installing ASP.NET MVC is simple and follows your standard, next, next, next, finish setup wizard.

And as an added bonus, MVC also works with Visual Web Developer 2008 Express, which is the free edition of Visual Studio for ASP.NET web development, which can be found here.

Choosing a Unit Testing Framework

Choosing a unit testing framework is simply a personal choice. Microsoft have included their own with Visual Studio 2008 (not express editions unfortunately), called MSTest. However my personal favourite at the moment is MBUnit/Gallio which can be found here. Most testing framework are fairly similar so if you are using a different one you should easily be able to translate my tests to your framework of choice.

Creating the MVC Project

If you start a new project in Visual Studio 2008 (or Visual Web Developer 2008) and select the project type “Web” under either Visual C# or Visual Basic (I’ve gone for C# as it’s my language of choice) you should see a template called “ASP.NET MVC Web Application”. Select the template and enter a Name for your project.

 

As you can see, I’ve given my solution the name of the software, and my project name is my solution name with .Web appended, this is my naming convention. This also makes sure that the default namespace for anything in my Web project is ArtistShowcase.Web .

Clicking OK will bring us on to the next part of the Project setup wizard.

As you can see, it’s asking me if I want to create a new Unit Test project for my MVC web project. As I’m going to be writing unit tests, I’m going to select yes. You’ll also notice that MBUnit shows up in here. This is small bonus for using MBUnit. MSTest also shows up in the drop down box, as you would expect, since it is Microsoft’s testing framework.

One thing to be aware of, is that you may never see this dialog if your using Visual Web Developer 2008 Express, as it' doesn’t support Unit Testing. So if you are using the Express edition, you’ll have to create your own class library that references your testing framework and your web project inside your solution.

After clicking OK will be present with our new solution, complete with Web Project and Testing Project.

 

This is a default project, that actually already contains some stuff, so there are a handful of unit tests that you can run, you can even run the project and get greeted with the basic MVC website.

However, I don’t want the default, and as much as starting off from this point can speed our development up, I want to start from scratch and go through all the headaches :)

So I’ve emptied the Content, Controllers and Models folder. I’ve deleted everything the views folder except the Web.config and I’ve also deleted the controllers folder from my test dll.

My Solution Explorer now looks like this:

Wrapping up

Okay that’s it for setting up the project and we should be okay to start coding and that’s all for this post.In the next post I’m going to go over the MVC directory structure and basic fundamentals of MVC and hopefully we’ll get to write our first line of code.

Introduction

I’m going to start a series about writing a web application using Test Driven Development and ASP.NET MVC. I’ll be learning as I go and this will basically be documenting what I learn as I learn it and hopefully in the end it will also be of some help to other people.

Defining the Application

Okay, so the application we’re writing here is a web app that allows Artists to showcase their work. It’s a simple application in concept, so lets define some basic functionality that is required, this functionality is simply the first bit of functionality we’ll implement to consider it our first release.

So basic functionality:

• Artist can upload images to a gallery
• Artists can create new galleries giving each a title and description
• Artist can give titles to images
• Artists can give descriptions to images
• Visitors can view images that have been organized in to galleries.
• Visitors can download images that have been marked as downloadable.
• There is an about page that the Artist can use to describe themselves.

Some functionality that isn’t so basic, but is wanted for the initial release

• Images viewed from website should have a watermark applied.
• Downloaded images do not have watermarks applied.

Some implied functionality

• Login system, so that visitors can be prevented from uploading images and administrating galleries.

And then some non functionality stuff that should be true

• Simple and well structured HTML that allows easy customization of website via CSS.

Initial Design

So first we need to translate these requirements into some basic design. But we’re doing TDD, I hear you cry, that should do the designing for us. Well the answer is no, we need to a basic design first to at least get an idea where to start. Our design needs to be basic so that it can be flexible because TDD may cause our design to emerge differently, via throwing up problems or issues or code smells that we haven’t thought of at this stage.

So lets take a look.

Users of the site

We have an Artist and a Visitor in terms of users of the site, only an Artist will be logging in, in order to administrate the site. This means that the defining difference between a Artist and a Visitor, is that an Artist is logged in and a Visitor isn’t.

So in our code, we’ll call an Artist a RegisteredUser and a visitor is called a GuestUser. Doesn’t match our stories, but it makes more sense in terms of web applications and are terms everyone is familiar with.

Our Domain

While I don’t plan on learning Domain Driven Design here, as I believe this site is too simple for such an approach since DDD is a way to manage complexity and complexity isn’t something we really have, we do have a domain. This is the domain of Artwork.

From our functionality list we can see that we have a Gallery and an Image

A Gallery has a title and a description and contains many images.

An image has a title and a description and will need some reference to the image data.

We also need someway to store information about the artist. We’ll call this the artist’s Profile

Data Storage

Our information needs to be stored somewhere, so looking at what we have and with a small amount of thinking, we have two places where we’ll need to store our data.

The Database and the File System.

The database will store details about our Users (or user in this case), galleries, images and the artists profile.

The file system will store the actual images in the format of the files uploaded.

Recap

Where’s the code and tests? Well we haven’t done any yet but we’ve outlined some basic things that allow us to see the basic direction of the application and should help us in figuring out where to get started. This initial design stage is important, and we’ll be doing design stages again in the future when we come to sit down and start writing units of functionality. In my head our order of work should be: Decide on piece of functionality to write, Basic design of functionality, Write tests and code in a test first manner allowing them to cause our final overall design to emerge and repeat.

See you next time.