Sitecore MVC and Ninject Part One


I recently finished up a Sitecore MVC (v. 7) project for a client and was able to successfully use the repository pattern, which is fairly standard in MVC development now days. Anyway, since doing this myself, I am taking this opportunity to write a series of posts that show how to get going in Sitecore development using the repository pattern together with Ninject. Part one will highlight the basic solution layout and explain what project files need to be created in the solution. Part two will demonstrate how to enable dependency injection in Sitecore. Part three will show how to put all the code together and then finally Part four will show how to use the code to display content on a rendering. One more thing worth noting is that this will also work with Sitecore 7, you will just need to ensure that the project is set to .Net 4.5 and not 4.

Part One

In part one, the focus will be in creating the solution in Visual Studio and the basic layout needed. First, we will need to create a new solution, so go ahead and open up Visual Studio and create a new blank solution (.Net 4) and name it as you would like. Next, create three solution folders:

  • UI
  • TDS
  • Dependencies

In the UI folder create the following projects:

  • <Root Solution Name>.UI
    • should be a blank MVC site, I use MVC 4, 3 works as well
  • <Root Solution Name>.Entities
    •  a blank class library
  • <Root Solution Name>.Services
    •  a blank class library
  • <Root Solution Name>.Models
    •  a blank class library

The TDS folder will contain TDS (Team Development for Sitecore). I always strongly recommend using this, especially when there are going to be large teams involved. Here is a link if you are curious – :

  • <Root Solution Name>.TDS.Templates
    • contains custom templates for the project
  • <Root Solution Name>.TDS.Layouts
    • Contains Layouts, Renderings, Controls (Items)
  • <Root Solution Name>.TDS.Core
    • This will contain customizations to Sitecore via the Core DB
  • <Root Solution Name>.TDS.DevContent
    • Content that is specific to Developers and not Content authors
  • <Root Solution Name>.TDS.Content
    • This will contain content during the beginning of the project and for the Dev server

In the dependencies folder, simply create a blank class library. Then create a folder to hold any assemblies that are going to be referenced throughout the project.

One useful thing that Visual Studio allows is the use of the ‘Configuration Manager’ to create multiple profiles. This comes in handy when setting up continuous integration into the lower environments, typically local dev box’s, the central dev server and qa server. Its usefulness is even further extended when using a Visual Studio add on called ‘SlowCheetah’, which allows for multiple xml configuration settings based on profile (no longer restricted to web.config only). I used to use simple xcopy post build commands, but a PM/Developer, Brian Ryther, at a previous engagement, turned me on to using this instead; it is much easier! First, let’s install SlowCheetah in Visual Studio (2012) by going to Tools > Extensions and Updates, then search for SlowCheetah. After installing it, now we will need to open the Configuration Manager by right-clicking the solution file and selecting ‘Configuration Manager’. After clicking the drop down called ‘Active Solution Configuration’, select ‘New’. Now, in the pop-up enter a name, usually that of the developer or target server and I usually always copy settings from ‘debug’. After that, make whatever needed changes to the new configuration file in regards to what needs to be built. Basically at this point, only the UI, Models, Services and Entities projects need to be built. More on using SlowCheetah will be available in Part 3 of this series.

Now that the bulk of the solution is laid out, we need to create the references that will be needed moving forward. This is fairly simple. First the Entities project will need to reference the Models project. The Models project does not need to reference anything. Next, the Services project will need to reference both the Models and Entities project. Finally, the UI project will need to reference the Services and Models project.

Now that we have a solution set up, we can start working on DI. More on this subject will actually be covered in part two of this series.

Part Two

One Comment Add yours

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s