Welcome back to my on-going series about the creation of GeoGeekTV.com. Now that I’ve got the routes all setup, it’s time to setup the solution.
Typically I break things up into (at least) 4 projects: Site, Domain, Data and Fakes.
Depending on what I’m doing I may create 3 more projects that will have unit tests for the previous three (I don’t create tests for the fakes!). Since this site will be pretty simple, I’ll likely skip unit testing for all but the most complex stuff.
So let’s see what’s in these projects
GeoGeekTV.Site
This is the actual ASP.NET MVC project. We’ll have the controllers, and the views in here, as well as some Html Extensions, Action Filters and Services. Since I like to use dependency injection to pass data repositories and other services into my controllers, I setup the mvccontrib WindsorControllerFactory. Since I’m using ASP.NET MVC 2 (Preview 1), I had to grab the /mvc2 branch of the source from github. Everything built smooth as silk, so all I did was grab the dlls and drop them into the /lib folder and make references.
Other items of interest… I’m using a custom authorization filter, which is based on the out-of-the-box Authorization filter that ships with ASP.NET MVC 1.0. Since the source for ASP.NET MVC is available, I could peek at what they did and just change a few things! It’s nice because it ties in with my custom Forms Authentication system, which uses an AccountModel. When a user logs in, their AccountModel is stashed away in session and is used by the Auth Filter to check a user’s roles. This allows us to avoid the Membership provider mess, and just implement things however we want to, all the while hiding the dirty bits behind a nice clean IAccountRepository interface.
GeoGeekTV.Domain
This is where the meat of the project lives – the domain model. In most projects we have the things we need to persist in the database as well as things like SelectLists that are just needed for the presentation in the UI. After trying a number of approaches, I’ve settled on keeping these things separate. The classes that are persisted to the database are “Models”, and the classes which contain the models as well as the UI extras are “ViewModels”.
This works well because we can create strongly typed views against our ViewModels, which allows us to have all the select-list-drop-down goop and the Model in one handy container, while still keeping them separate behind the scenes. We’ll see how this comes together in a later post.
We also have some utility classes in here, as well as the interface definitions for services and repositories.
GeoGeekTV.Data
This is the data access layer, and we’ll have classes in here that will implement the IRepository interfaces. For now there’s nothing in here, but eventually we’ll have our NHibernate stuff in here.
GeoGeekTV.Fakes
This is where we fake it till we make it. Basically we implement the interfaces in here, and just return valid, but fake data. This allows me to build out pretty much the entire site without every creating a database. Since it’s just code, any refactoring of the domain or data access interfaces has limited ripple effects. And since we use dependency injection in our controllers, we just change one line of code and the app switches over to the real implementation in the Data project.
Ok, that’s the solution. Next up: Implement the design via a master page.
