Now that ASP.NET MVC has been around for a while there have been plenty of articles written about how leverage the technology to create powerful, lightweight web applications which are highly customizable and testable. I’ve discussed the advantages of using ASP.NET Forms and ASP.NET MVC plenty of times in the past, but just so no one thinks I am a forms hater I will say that I still create forms applications. Both MVC and Forms can coexist and they both have their advantages.
I will say that there is of course a learning curve for MVC. You don’t instantly know it just because you’ve used web forms. So yes, it will be like learning any new technology. However, I am writing this so that a transition can be easier. Rather than doing some demo application that doesn’t take into consideration real-life situations and circumstances I’ll be posting about an application I’ve been working on.
Background Information and Reason for Creating the Site
I am a member of the Boardgamers Of Greater Akron (BOGA), which if you hadn’t guessed from the name is a group of people who gather together the second Friday of every month to play board games. As games are completed the stats from the games are recorded onto sheets of paper and these stats will later be entered into a database.
Initially the founder of the group had been entering these game logs into the system using a local web forms application using the standard data entry controls. The entire site took about half an hour to an hour to create, so as you can guess it was kind of clunky and hard to use. From the data, I was able to write a bunch of SQL queries that were then used to calculate the stats from these games.
Creating the Solution, MVC Project, and Web Tests Project
I like to start by creating a solution first. I don’t want Visual Studio to create the solution for me because it will do a lot of stuff for me. I want to have control of the structure of my application, so I am going to create that first. This will let me organize my software project. To create a solution just create a new project of type Blank Solution. You can find that in the Other Project Types –> Visual Studio Solutions category.
I named the solution based on the domain of the application. This is important to do since I don’t plan on referencing the domain in any of the projects in this solution. Since names get long and difficult to work with sometimes I am going to stick with shorter ones. I’ll alter their default namespaces so it is a little bit easier to deal with.
Before we can write any code we have to have a project in which to write this code, so how about if we create a new MVC project. I’ll name it based on the domain of our application, so I’ll go with Web. Since the
Since we created this as an MVC site we will be prompted with the option to create a test project. Your Test Framework options will be populated with the test frameworks that you have installed that Visual Studio knows about. In this case I am just going to go with the Visual Studio Unit Test Framework since it defaulted to that. The differences between this and NUnit are negligible anyway.
After you wait for Visual Studio to create the projects for you the following will appear in the Solution Explorer. The first step is deleting the AuthoringTests.txt file. Not sure why that needed to be included every single time a project is created. Maybe there is some way to turn it off just so I don’t have to delete it. Well it doesn’t matter anyway.
I might also delete the App.config file, but there really isn’t much there to worry about. The use of the App.config in testing should be discouraged. If you’re having to put something in there then you have too much dependency on that. Keep in mind that the App.config in a test project should only include test configuration information. If it is using anything that is normally in the production configuration then you’ve got something you need to fix.
Creating the Core and Infrastructure Projects
Our next step is to create a project where we will keep the core logic of our application. This is business layer, but I don’t like that name because business logic often ends up getting mingled with infrastructure concerns. I am naming the next project Core to mean that this is central to the application. Only the things that are core parts of the application go here.
So as usual I need to make a couple of modifications. First I delete the silly Class1.cs file and then move the Models from the web project and move it here. I would say that the domain objects that we are going to be dealing with deserve to be in our core application.
The Infrastructure is the next step. If you expect to have multiple infrastructure concerns that you want to separate into separate libraries go with a more specific name for this project. Since I expect to only deal with database concerns I will stick with a generic name> If I ever need to change things I am not too concerned since renaming things is actually really easy if I structure my application nicely and use refactoring tools to help.
Once I create this I will of course delete the Class1.cs file and I will end up with a pretty full Solution Explorer now. I’ve got most of the projects in place now. I could have started small here, but I know I am going to need these projects.
Creating the Unit and Integration Test Projects
Since I like to keep the unit and integration tests separated from the production code it is nice to keep them in a separate library. This means that the tests need not be included with the rest of the application in deployed scenarios. The only problem I can think of is keeping the tests in their own library could make them just another navigation headache. However, since I use ReSharper I have a navigation tool which allows me to quickly get to anything based on its name, so I am not concerned with that issue.
Since I am using MSTest for my testing framework I can use the Visual Studio Test template. If you’re using something else like NUnit you will just create a normal class library and include a reference to the NUnit dll.
Since we created this from the UnitTest project template it added in the reference to the dll required to use MSTest. However, we will also need to eliminate these files which were created for us.
The next step is an integration test library. These tests are very important in the project as they help us ensure that everything is working well together. We want all the individual pieces working, but knowing that they interact is just as important. We keep them separate because the integration tests can often be long-running and we want to be able to execute the unit tests first. They will run faster and if there are any issues we will know sooner. Creating the integration test project will be done the same way we created the unit test one.
And as usual we have a few files that we do not need. Time to delete them.
I will soon discuss setting up the build process using NAnt and the continuous integration process using CruiseControl.net. As you may have noticed I think the structure of software projects and the initial setup are very important. Without build systems in place I think the development process can be very limiting.
Comments