Contents tagged with CodeStore
Although there is not much in this project yet but I think there are few things that can be improved before moving ahead.
Moving castle configuration from the App.config file to its own file:
This is to remove the noise in the main application configuration file and it is as simple as extracting the castle configuration items into another file and passing that file name in the WindsorContainer constructor.
Abstract IOC container:
It is a good idea to abstract dependencies and therefore the reason of DI containers. But what about the DI container itself. One way to do this is to abstract it behind a separate class IOC.cs
Moving the engine implementation into a separate namespace.
Using Hudson as a Continuous Tool:
I have used CC.NET before and I remember that it wasn't a smooth setup. So for this project, I've decided to try Hudson.
Hudson is built on Java but it is extremely easy to setup and the .NET plugins for MsBuild, Nant, Nunit and support for running batch files makes it a viable alternate to CC.NET. I found an excellent tutorial (http://redsolo.blogspot.com/2008/04/guide-to-building-net-projects-using.html) on setting up Hudson for .NET projects and believe me, it just works.
Once I completed the setup, the hudson dashboard looks like this. I've also checked in the configuration file that I used for this project.
In this post, I've done some small refactoring on the project structure and then used Hudson as a CI tool. In the next post, I'll start putting in more functionality into the project.
So, in the last post, I started creating a new application using TreeSurgeon and added Castle Windsor and log4net support. In this post, I'm going to describe how I added the Nhibernate support and the Castle Nhibernate facility.
Because CodeStore is about storing metrics about an Assembly therefore I'm going to start by storing the assembly information. Therefore the first user story is:
1) As a customer, I want to query the Assembly data in the database so that I can get metrics about the assembly.
After breaking the story into tasks, we have:
a) Read Assembly Data
b) Store Assembly Data in SQLite using Nhibernate.
Although we can start with any task, but in this scenario I'll go with the second task which is about setting up Nhibernate to store data in the SQLite database.
There are few things we need to download and setup before start coding.
- Download SQLite ADO.NET Database Provider (http://sqlite.phxsoftware.com/). The good thing about this provider is that it embeds the sqlite database engine so you don't need any more dependencies.
- Download SQLIte Database Browser to manage the database (http://sqlitebrowser.sourceforge.net/) but you can also use the native sqlite engine to manage the database from console.
- Download NHibernate.
Once we have the required dependencies, we can start by creating a new datastore. SQLite Database Browser allows you to create a new database but you'll have to create a temporary table so that it can save it in the file.
Then I added a new class AssemblyData in our Core.Domain namespace.
Once all the fields are defined, I generated all the properties using Resharper (Alt+Ins)
It seems that Resharper doesn't generate the auto properties so you'll have to fix it (Ctrl + Enter).
Or you can just type the auto properties without any help which may be the quickest option :).
The next step is to create the nhibernate mappings file. When editing the mapping file, it is much better to add the nhibernate mappings schema to get intellisense in the IDE.
The complete mapping file looks like this. The build action should be set to embedded resource.
<?xml version="1.0" encoding="utf-8" ?>
As we have the domain class and the corresponding mapping file, we can configure the application to use Nhibernate. For that, I created a separate hibernate.cfg.xml file in the Core application with the following contents. The properties are self-explanatory and you can always learn more by looking into the Nhibernate documentation.
<?xml version="1.0" encoding="utf-8" ?>
<property name="connection.connection_string">Data Source=E:\Code\CodeStore\data\codestore.db;Version=3;New=False;Compress=True;</property>
To check whether the configuration is correct, I quickly wrote a test to generate the schema for the above domain model.
public class HibernateTest
public void CanExportSchema()
var cfg = new Configuration();
new SchemaExport(cfg).Execute(false, true, false, false);
The above code will generate the AssemblyData table in the database with the defined fields.
So this is one approach to design (domain driven design) where we started with our domain model and then generate the database in the end. The other side of it is data driven design where you can start with the database and generate your domain from these entities. By using the database, you can also generate the plumbing code for domain model (i.e. Mapping files and Domain classes) using some generation tool like MyGeneration or CodeSmith.
Now, using the Repository pattern, I'm going to create a repository to save assembly data into the database.
Although not TDD, but writing a test now.
Currently we are using plain vanilla Nhibernate through the NHibernateHelper which is not a bad thing but there is Castle NHibernate facility that we can utilise and abstract the Nhibernate plumbing. To do so, there are two different types of integration styles (defined here) I'm using the second approach which looks more straight forward.
The first thing is the change in configuration file. The hibernate configuration is currently defined in a separate hibernate.cfg.xml file which I'm going to move into the app.config file inside the existing castle/facilities section.
The second thing is to change the repository class to inject ISessionManager (link) in the constructor.
And then you can use the data repository as:
Source Code: http://code.google.com/p/code-store/
In this blog post, we started with creating a database and the domain model for storing AssemblyData. In the next post, we are going to use mocks to test the repository.
As always, comments and suggestions are most welcome to improve the project.