Cricket.Net: Part 2 – Design Discussion

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:

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.


  • 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:
Download the source code from this post at:

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *