Website Development

Cricket.Net: Part 2 – Design Discussion

Oct 13th

Posted by Chris Jackson in Programming

Summary
Cricket.Net is a new open source project that I’ve started on Codeplex. It will be a web application that will be used for tracking software bugs. Cricket.Net will be written in C# using HTML5, ASP.NET MVC 3, Entity Framework 4.1 Code First, StructureMap, and the Onion Architecture. This project will be an example application to demonstrate how to use these technologies together to build a web application from the ground up.

I’ll also be going through using Mercurial both on my system and pushing changes to the Codeplex site.

Cricket.Net Series:

Part 1: Setting up the initial project
Part 2: Design Discussion
Part 3: Unit Testing

What will the application do?
I’m going to take a step back before continuing with the code and look at what this application is suppose to do. I don’t need to determine everything up front, instead I’m going to use an Agile approach and lay down some basic requirements for what the system is suppose to do and if those change as the development progresses, that is fine.

Ususally the first thing I do is think about what information the application needs to store. Cricket.Net is a bug tracking program, so it will need to store information on a specific bug and what application the bug occurred in. I’m also going to want to track dates for when the bug was created and resolved, the version of the application the bug occurred in and maybe a list of one or more assignees who are working on resolving the bug.

Next, I’m going to open up Visio and separate these ideas into objects on a database model diagram. Since I’ve already created my solution folder, I’m going to add a folder within it called !Design. I’ll place all of my design files here to keep them with the solution when I update the Mercurial repository.

You don’t necessarily need to create a diagram of the database, you could just write-up the code using Entity Framework: Code First, but it is nice for non-programmers to have something to look at. Also, complex databases with many relationships can be difficult to work with if you don’t have a diagram to look at.

Onion Architecture and StructureMap
Now I’d like to talk for a minute about the Onion Architecture. Structuring an application in this way separates the business logic from the web and infrastructure components in a way that limits their dependencies on each other. Take a look at the following diagram:

The blue boxes represent a project within the solution. The arrows point to their dependencies. Notice how all projects depend on Core. This is where the business logic classes and interfaces are found. Also, notice how the Web project (in this case will be MVC 3) does not depend on Infrastructure (where the database repositories reside). There is an indirect dependency through the DependencyInjection project. This is where StructureMap (or another IoC framework) lives. StructureMap will wire-up the dependencies between the Web and Infrastructure frameworks using the interfaces found in the Core project.

Why go through all this work to setup your project this way? Encapsulation of components that could be replacable in the future makes it easy to upgrade an application to those new componenets. With Onion Architecture you could switch the entire application over to a different database server and only have to modify the database classes found in the Infrastructure project. As long as the interfaces do not change for those classes, the reset of the application will work as it did previously. This can save much time over rewriting the entire application because the db code is embedded everywhere.

The UI component could be changed as well (in this case the Web project) for a console application. The Core and Infrastructure will function the same, but the application would appear totally different.

Projects Summary:

UnitTests – As the name implies, it contains all unit testing code. The Moq mocking framework will be used here.
Web – This is the user interface project. This contains the controllers, views, view models, and wrapper classes around MVC or web specific operations.
Core – This contains all interfaces for the application and business logic including: the domain model and service classes.
DependencyInjection - This contains the classes needed by StructureMap. StructureMap will register all interfaces and concrete classes used in the application.
Infrastructure – This contains any IO wrappers or classes using 3rd party projects (including our own common projects).

Unit Testing
When starting a project, I try to get in the habbit of coding a Unit Test first, before anything else. This helps me think about how I want to use a method before I worry about how the method works. This tends to lead to an overall better design of the application. I also try to adhere to the SOLID principles, DRY, and YAGNI by only coding what is needed at the time.

Unit Tests should also be very simple. Test for one condition to be met and pass or fail.

Requirements

Allow users to manage Applications (including adding different versions for each).
Allow users to manage their issues.
Allow users to be managed by users.
(Managing each of these includes listing, adding, creating, editing, and deleting).

Visit the project site at: http://cricket.codeplex.com.
Download the source code from this post at: http://cricket.codeplex.com/SourceControl/changeset/changes/a115ce901573

ASP.NET MVC, Onion Architecture, Tutorial

Cricket.Net: Part 1 – Setting up the initial project

Oct 12th

Posted by Chris Jackson in Programming

No comments

I’ll also be going through using Mercurial both on my system and pushing changes to the Codeplex site.

Cricket.Net Series:

Part 1: Setting up the initial project
Part 2: Design Discussion
Part 3: Unit Testing

Prerequisites
To get started, I’ll be using Visual Studio 2010 SP1Rel and ASP.NET MVC 3 Tools Update. Later, I’ll be using Entity Framework 4.1 Update 1 so that I can use Code First. You can either download and install Entity Framework, or we’ll attempt to install this from the Nuget package first.

Creating A New Project
Initially, I’m going to start with the basic MVC package created by Visual Studio. After this package is created, I’m going to create the Mercurial repository so that I can send the code to Codeplex.

Open Visual Studio 2010.
Click the File menu, then New, Project.
In the New Project window, under Installed Templates, expand Visual C# and choose Web. Select the template called “ASP.NET MVC 3 Web Application.” The Name field will be the default name and namespace of your initial project, the Location will be the folder on your C:\ drive where to store your solution, and the Solution Name is the name of your solution folder (if you wish it to be different).
After clicking OK, the New ASP.NET MVC 3 Project window pops up. I’m going to choose Internet Application so that the tooling will allow me to go ahead and create a Unit Test project also. I’m going to change the name of the Unit Test project to Cricket.UnitTests.
After Visual Studio finishes creating the project, it should look like the image below. The Internet Application template that we had chosen in the previous step has added some files that will may or may not use, but for now we’ll leave these in the solution and move on to creating the Mercurial repository.

Setting up the Mercurial Repository
If you are unfamiliar with Mercurial, it is a source control application that is very fast and pretty easy to use. Before you can continue with this tutorial, you will need to install at least TortoiseHg to manage the Mercurial repository from Windows Explorer. If you’d also like to work with it from within Visual Studio, you will need VisualHg. If you’d like to know more about what Mercurial can do, check out this video from tekpub.com.

If you still have your new solution open in Visual Studio, go to the File menu and choose Close Solution.
Next, browse to the folder where your solution folder is located. (In my case, I need to go to the C:\Users\cjackson\Documents\All Projects\ folder)
Right-click on the Cricket.Net folder and expand the TortoiseHg context menu and choose Create Repository Here.
TortoiseHg will display an Init window. Click the Create button to create the repository.
After the repository has been created, a green check mark icon will appear over the Cricket.Net folder icon.
Open the Cricket.Net folder and then edit the .hgignore file. This file will tell the repository to ignore certain files/folders that are used by Visual Studio and do not need to be version controlled. Paste the text below into the file and save it.

# use glob syntax
syntax: glob

*.obj
*.pdb
*.user
*.aps
*.pch
*.vspscc
*.vssscc
*_i.c
*_p.c
*.ncb
*.suo
*.tlb
*.tlh
*.bak
*.cache
*.ilk
*.log
*.lib
*.sbr
*.scc
[Bb]in
[Dd]ebug*/
obj/
[Rr]elease*/
_ReSharper*/
[Tt]humbs.db
[Tt]est[Rr]esult*
[Bb]uild[Ll]og.*
*.[Pp]ublish.xml
*.resharper

Next, I’ll save the initial project into the Mercurial repository.

Return to the folder where your solution is stored. (C:\Users\cjackson\Documents\All Projects\ folder)
Right-click on the Cricket.Net folder and choose Hg Commit…
The Cricket.Net commit window will pop up. On the left pane, click the check box at the top to select all files then in the top-right pane, type in a comment for the commit. After you enter whatever comments you wish, click the Commit button to save the current state of the solution.
Next, for new untracked files, a window may pop up asking to add untracked files. Click Add.

To save the current repository to Codeplex, follow these instructions:

Return to the folder where your solution is stored. (C:\Users\cjackson\Documents\All Projects\ folder)
Right-click on Cricket.Net and expand the TortoiseHG context menu and choose Synchronize.
Under Remote Repository, change the drop down to HTTPS and enter the name of the repository so the URL looks like this (http://hg01.codeplex.com/cricket)
Click on the icon to push changes to Codeplex.
Enter your Codeplex username and password when prompted and the files will be uploaded to Codeplex.