ChopShop: A MVC.NET E-Commerce project

I decided to start a little open source project recently.  The idea was that it would allow me to flex some programming muscle, play around with some technologies I wouldn’t be allowed to use at work now and generally make my karma better by giving back (to whoever decided to pick it up) – who knows, it may be the next Magento (yeah right!).  Over the course of this coming year I’m hoping to carry on working on this project and documenting some of the decisions I’ll be making around the codebase.

High Level Architecture Decisions

Although I have a features list in mind that’s about a mile long, my intention, with regards to code architecture, is to keep things as simple as possible.  The application will be split into two websites – one for the front end (the Shop) and an administrative back end.  Keeping scalability and performance in mind, the idea would be to allow the front end to be customised/expanded independently of the admin site – the only thing linking the two would be the database.

My web application of choice will of course be ASP.NET MVC 3 using C# 4.  Database persistence will be handled by NHibernate 3 and the entire thing will be glued together with Castle Windsor 2.5 and jQuery.  I’ve opted for a fairly typical (I think) n-tier logical architecture liberally using Interfaces to keep the layers separate.

The general pattern to get data from the database to the browser would be for the Controller (in the Web project) to request some data for a View Model from a Service. I’ve opted for a very simple Repository pattern allowing Windsor to inject dependencies for me based on the “WithFirstInterface” convention. The service would then request data from the repository, pass it to the Controller, which then gives it to the ViewModel to mash together into whatever the View requires.  There is some implementation leakage from the Repository layer into the Service layer, but that is acceptable due to the dependency on NHibernate in the first place.  I felt that keeping things DRY and SOLID far outweighed any perceived need to change out the ORM at any future stage (thus also sticking to YAGNI).

So far, so very simple, but then again I’ve been mainly working on putting the framework together for the Admin site.  The architecture for the Shop could look different (but only very slightly).  One of the most fundamental architectural decisions in this project is that each component must be swappable (with the exception of the data access layer).  One of my aims is to have multiple payment providers, so being able to have a plug and play architecture will be vital.  Designing the application this way should also allow for each component to be tested without affecting any other components.

The TL;DR architectural summary then would be:

  • Take a dependency on NHibernate
  • Take a dependency on ASP.NET MVC 3
  • Separate layers/components intelligently with Interfaces
  • Glue the layers/components together with Castle Windsor
  • Create a series of unit tests around each component


Project Management

The biggest problem I’ve traditionally had with doing little projects like these in the past has been the lack of focus around what it is exactly I want to achieve.  To combat this, I’ve taken to using to record all the different user stories that I want around the creation of this application.  To date there’s around 52 stories and so far I’ve only managed to complete 1(!).  The downside to User Stories is that they don’t take frameworks and infrastructure into account.  The User may only care about adding a Product to their Catalog, but without a supporting framework in place very little can be done.  I’m still not sure how I could approach that kind of “start up” problem better – I’m sure it’ll come to me the more projects I start up.


Leave a Reply

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