Jakob Andersen

Miracle Open World 2010 - Development track

Jakob Andersen — Fri, 12 Feb 2010 01:31:00 +0200

The company that I work for Miracle has a reputation. A reputation for throwing some exiting and very social konferences. Usually the themes have been either Oracle or SQL Server but this year this has changed. The Oracle and SQL Server folks will have to get a long and furthermore we have added a Microsoft development track and a workshop track, so I bet the discussions over the drinks and dinner will be a little less onesided this year.

The venue is Lalandia/Legoland in Billund and everything is included in the conferencefee: food, drinks, accomedation and off course access to the galladinner and the legendary beachparty held in the venues waterpark (Don't miss this, its a blast).

I have been involved in the planning of the development and workshop tracks and i thought it would fit me to write a little bit about the speakers i have invited to talk at the event and why i look forward to a couple of exiting days in April:

Rasmus Kromann-Larsen will demonstrate his mad ninjaskills with ReSharper and im pretty sure that when you leave the talk you will have a few extra tricks up your sleeve to improve your productivity when writing and navigating around code. Rasmus second session will discuss some practical experiences from an ASP.NET MVC implementation project, so if you still miss to see how ASP.NET MVC will work in the wild compared to webforms you should definitely go.

Mads Kristensen from Vodafone is a really weird guy compared to most of the .NET developers i know. Mads look on performance has a strong focus on things like renderingtime in the browser and how much data we send to the clients. This aspect of performanceoptimization is often missed and if you have struggled to reduce the waittime in your serverside code I bet you that Mads will show you some tricks that can improve the response time from the users point of view.

Mark S. Rasmussen from iPaper knows a lot about working with existing PDF documents. Mark has had the technical responsibility from building the iPaper solution from scratch. He will show you how to work efficiently with large PDF documents and what information you can extract from them. Furthermore Mark secretly wan't to be sysadm so he loves monitoring performance of his systems, thats why his second talk will talk about end-to-end tracing of your applications across infrastructure points and including the database.

Have you ever heard of WinDBG? If you haven't you missed out on of the most valuable tools for debugging the really tough problems like deadlocks or memoryleaks in both managed and unmanaged code. Brian Rasmussen who works at SimCorp is an expert on WinDBG and a really good speaker. Brian will present a session about WinDBG and if you really want to get messy he will host a workshop where you can explore the wonders of WinDBG in more depth. On a personal note i can add that WinDBG has been one of the favorites in my toolbox since i first learned to use it.

Adding to the above speakers we have some very skilled Miracle employees that will present on the development track:

Anders Lybecker is going to talk about the full-text search framework Lucene.NET. Anders has reallife experience with Lucene.NET from several projects with large amounts of data and demands for fast searches with continious updating of the searchindex.

Simon Clemen Pedersen is going to take you on a guided tour in the jungle of javascript frameworks and show how you can keep a clean and maintainable codebase when working with the Dojo javascriptlibrary.

I am going to give a few talks aswell. First of i will introduce how we can measure an applications throughput to create a performancebasline for the application. This baseline can be used to find the knee in performancecourves aswell as monitoring performance across new releases. My second talk will discuss different caching strategies in applications. Lastly im going to give a talk on some of the more exotic features in nHiberante like Sharding, Validators and Caching.

Even though you might see yourselv as a developer type a lot of interesting topics is on the SQL Server and Oracle tracks aswell. Topics like: how to work with huge databases, SQL Server Integration Services,, how to write effective SQL, XML in the database. And of course a lot of topics on performance and scalability. One of my "odd" but must-see sessions is Toon Koppelaars "Applied Mathematics for database professionals", i have heard the talk once before and its about how to use basic mathematics to formally describe difficult SQL Queries, and hence use mathematical rules to simplify or optimize the queries, that session is highly recommended!

We are still working on completing the speakerlineup, so if you have any suggestions please let me know, and i will see if we can make it happen.

Registration and more information is available on: mow2010.dk

If you have any questions about the programme or the konference in general feel free to contact me on jta@miracleas.dk

Writing a calculator in C# using Irony

Jakob Andersen — Wed, 07 Oct 2009 14:42:00 +0200

My friend Mark wrote a post last week about implementing a calculating compiler using SableCC. I have worked with SableCC on a project where we needed to parse C# code and I have to admit I don't recall SableCC as a friendly framework, and reading Mark's post proves my memory right.

First of Mark's grammar is very specific to SableCC, a lot af tricks is made to make SableCC accept the grammar and furthermore the grammar is complicated further by handling operator precedence. If we disregard performance considerations and focus on an easily understandable and maintainable compiler structure our grammar for our parser generator ideally would look very much like the Extended Backus Naur Format (EBNF) of the language.

number = digit+ | digit+ '.' digit+
lparen = '('
rparen = ')'
binop = '+' | '-' | '/' | '*' | '%'
funcname = letter+
expression := lparen expression rparen | expression operator expression | funcname lparen expression rparen | number

Irony is like SableCC a scanner/parser generator but it is implemented as an internal DSL in C# for specifying grammars on a format very close to EBNF. The code is specified in the constructor body of a class inherting from Irony's Grammar class. The EBNF described above (slightly modified for readability) looks like this:

public class SimpleCalcGrammar : Irony.Parsing.Grammar{
    public SimpleCalcGrammar(){
        var number = TerminalFactory.CreateCSharpNumber("number");
        var identifier = TerminalFactory.CreateCSharpIdentifier("identifier");
        var expression = new NonTerminal("expression");
        var binexpr = new NonTerminal("binexpr");
        var parexpr = new NonTerminal("parexpr");
        var fncall = new NonTerminal("fncall");
        var binop = new NonTerminal("binop");
            
        expression.Rule =  parexpr | binexpr | number | fncall;
        parexpr.Rule = "(" + expression + ")";
        binexpr.Rule = expression + binop + expression;
        binop.Rule = Symbol("+") | "-" | "/" | "*" | "%";
        fncall.Rule = identifier + "(" + expression + ")";
        this.Root = expression;
        //...
    }
}

The first few lines are initialization of our Terminals and Productions, this is pretty trivial however a few things is worth noting. Irony is a very rich framework that provides a lot of prebaked functionality, one of these is the TerminalFactory for creating typically used terminals, in our case we use C#'s format for numbers and identifiers, that means we out of the bag get support in our language for suffix on numbers for specifying types etc.

The interresting part is after initialization, here we set up rules for the productions. Irony relies heavily on operator overloading so using our productions and the operators from EBNF we can describe the language pretty straight forward. Lastly we specify what productions is the root of our program, that is the production that contains the entry point for the whole language.

Next up we need to handle operator precedence, fortunately Irony knows that this is a common challenge when developing languages and hence it supports registering our operators and their precedence using the following code:

RegisterOperators(1, "+", "-");
RegisterOperators(2, "*", "/", "%");

Having specified this we have a working parser that can be used like this:

SimpleCalcGrammar g = new SimpleCalcGrammar();
Parser p = new Parser(g);
ParseTree t = p.Parse("25-37+2*(1.22+cos(5))*sin(5)*2+5%2*3*sqrt(5+2)");

This gives us a parse tree that is pretty rough in the edges and hard to work with, what we want instead is a pretty Abstract Syntax Tree that contains exactly the information we need. On our NonTerminal instances we can specify which nodes they should be transformed into, fortunately Irony contains some of the basic nodes that are needed in many languages for instance the binary expression node, so we can specify the built-in BinExprNode on our binexpr NonTerminal like this:

var binexpr = new NonTerminal("binexpr", typeof(BinExprNode));

For us to parse the language we need one aditional node in our AST, that is the FunctionCall node (the observant reader might have noticed i have choosen to implement an openended grammar that allows for extending with new built-in functions without modifying the grammar). Irony has a AST node for function calls built-in but for the sake of the example i will show a custom implementation here:

public class FunctionCallNode : AstNode{
    public string Name;
    public AstNode Argument;
    public override void Init (Irony.Parsing.ParsingContext context, Irony.Parsing.ParseTreeNode treeNode)
    {
        base.Init (context, treeNode);
        Name = treeNode.ChildNodes[0].FindTokenAndGetText(); 
        Argument = AddChild("Arg", treeNode.ChildNodes[1]);
        AsString = Name; 
    }
}
//Adding the node to our function call node
var fncall = new NonTerminal("fncall", typeof(FunctionCallNode));

So implementing our own AST nodes is pretty simple, and Irony has a rich infrastructure for getting text of tokens and adding childnodes as you can see in the sample. Because our parse tree contains a lot of "garbage" that we don't want transferred to our AST, so we need to inform Irony to import these, this is done by marking nonterminals as transient like this:

MarkTransient(parexpr, expression);

And at last we need to set a flag so that the parser generates the Ast using the following line of code:

LanguageFlags = LanguageFlags.CreateAst;

The next step is to actually work with the AST for sementic analysis, codegeneration or as in our case execution of the calculation. Mark did this using a visitor and Irony's AST supports visitors aswell, so we can make the "PrintVisitor" mark used for debugging like this:

public class PrintVisitor : IAstVisitor{
    int indentation = 0;
    public void BeginVisit (AstNode node)
    {
        for (int i = 0;i<indentation ;i++ ) {
            Console.Write("\t");
        }
        Console.WriteLine(node.ToString());
        indentation++;
    }
    
    public void EndVisit (AstNode node)
    {
        indentation--;
    }    
}

Using a visitor looks like this:

SimpleCalcGrammar g = new SimpleCalcGrammar();
Parser p = new Parser(g);
ParseTree t = p.Parse("25-37+2*(1.22+cos(5))*sin(5)*2+5%2*3*sqrt(5+2)");
var astnode = (AstNode)t.Root.AstNode
astnode.AcceptVisitor(new PrintVisitor());

And the result of this operation is:

+(operator)
    Arg: +(operator)
        Arg: -(operator)
            Arg:25
            Arg:37
        Arg: *(operator)
            Arg: *(operator)
                Arg: *(operator)
                    Arg:2
                    Arg: +(operator)
                        Arg:1.22
                        Arg: cos
                            Arg:5
                Arg: sin
                    Arg:5
            Arg:2
    Arg: *(operator)
        Arg: *(operator)
            Arg: %(operator)
                Arg:5
                Arg:2
            Arg:3
        Arg: sqrt
            Arg: +(operator)
                Arg:5
                Arg:2

However, there is no need for us to create a printvisitor, Irony comes with an UI that allows us to work with our grammar and can parse samples and show us AST, parsertrace with parserstatec and much more, this is very useful to see what the grammar actually does under the covers (shift/reduce). But basically we can go ahead and implement pretty much the same visitor as Mark have used for SableCC, but let's do something different. Irony has support for a basic LanguageRuntime, and actually for a basic interpreter aswell. So if we tell our AST-nodes how they should evaluate themselves we get all the infrastructure given to us by Irony!

So lets override the Evaluate method on our FunctionCallNode so it can be used in Irony's interpreter infrastructure:

public class FunctionCallNode : AstNode{
    //....
    public override void Evaluate (Irony.Interpreter.EvaluationContext context, Irony.Ast.AstMode mode)
    {
        Argument.Evaluate(context, AstMode.Read); //Evaluate the argument the result is saved in context.Data
        double input = Convert.ToDouble(context.Data[0]);
        double result;
        if(Name == "sqrt"){
            result = Math.Sqrt(input);
        }else if(Name == "cos"){
            result = Math.Cos(input);    
        }else if(Name == "sin"){
            result = Math.Sin(input);    
        }else{
            throw new NotSupportedException("Method " + Name + " not supported");    
        }
        context.Data.Replace(1, result); //Replace the argument value on the stack with the result of the function call
    }
}

Yes, in real life our methods would be in a method table and not hardcoded here, this is just to demonstrate the functionality of the interpreter in irony. To use the Interpreter we write code like this:

var interpreter = new Irony.Interpreter.ScriptInterpreter(new LanguageData(new SimpleCalcGrammar()));
interpreter.Evaluate("25-37+2*(1.22+cos(5))*sin(5)*2+5%2*3*sqrt(5+2)");
Console.WriteLine(interpreter.EvaluationContext.LastResult);

Voila, done with the code that corresponds to Mark's sample and the result of running the above is: -9.83033874894108 and the built-in Irony interpreter handle almost everything for us leaving me with only 57 lines of pure C# code:

public class FunctionCallNode : AstNode{
    public string Name;
    public AstNode Argument;
    public override void Init (Irony.Parsing.ParsingContext context, Irony.Parsing.ParseTreeNode treeNode)
    {
        base.Init (context, treeNode);
        Name = treeNode.ChildNodes[0].FindTokenAndGetText();
        Argument = AddChild("Arg", treeNode.ChildNodes[1]);
        AsString = Name;
    }
    
    public override void Evaluate (Irony.Interpreter.EvaluationContext context, Irony.Ast.AstMode mode)
    {
        Argument.Evaluate(context, AstMode.Read);
        double input = Convert.ToDouble(context.Data[0]);
        double result;
        if(Name == "sqrt"){
            result = Math.Sqrt(input);
        }else if(Name == "cos"){
            result = Math.Cos(input);    
        }else if(Name == "sin"){
            result = Math.Sin(input);    
        }else{
            throw new NotSupportedException("Method " + Name + " not supported");    
        }
        context.Data.Replace(1, result);
    }
}
public class SimpleCalcGrammar : Irony.Parsing.Grammar{
    public SimpleCalcGrammar(){
        
        var number = TerminalFactory.CreateCSharpNumber("number");
        var identifier = TerminalFactory.CreateCSharpIdentifier("identifier");
        var expression = new NonTerminal("expression");
        var binexpr = new NonTerminal("binexpr", typeof(BinExprNode));
        var parexpr = new NonTerminal("parexpr");
        var fncall = new NonTerminal("fncall", typeof(FunctionCallNode));
        var binop = new NonTerminal("binop", "operator");
        
        expression.Rule =  parexpr | binexpr | number | fncall;
        parexpr.Rule = "(" + expression + ")";
        binexpr.Rule = expression + binop + expression;
        binop.Rule = Symbol("+") | "-" | "/" | "*" | "%";
        fncall.Rule = identifier + "(" + expression + ")";
        
        RegisterPunctuation("(",")");
        RegisterOperators(1, "+", "-");
        RegisterOperators(2, "*", "/", "%");
        
        
        MarkTransient(parexpr, expression);
        
        this.Root = expression;
        this.LanguageFlags = LanguageFlags.CreateAst;
    }
}

Why I love extension points - nHibernate Driver

Jakob Andersen — Wed, 26 Aug 2009 01:01:00 +0200

I have used nHibernate on linux for some time now without any major problems. The issues I have encountered have infact not been with Mono but with the MySql dialect in nHibernate. One of these where a nasty issue where nHibernate closed the connection to the database before retrieving the newly generated identifier which (in this case) unfortunately is bound to the current database connection. However I made a fix for this in the MySqlDialect and now it should be committet to nHibernate repository be included in next release.

Today I was starting a new project writing some tests and wanted to use SQLlite in memory for some pseudo integration testing, Mono has built-in support for SQLite in the Mono.Data.Sqlite assembly however nHibernate isn't aware of this and hence espects that you have the SQLite.NET assembly and the SQLite binaries present either in your bin directory or in the GAC. To avoid having to deploy these on my linux box which already has a .NET implementation of SQLite's IDbConnection and IDbCommand i turned to one of the extensions points in nHibernate and made my own Driver as follows:

public class MonoSqliteDriver : NHibernate.Driver.ReflectionBasedDriver
{
    public MonoSqliteDriver() : 
        base("Mono.Data.Sqlite",
        "Mono.Data.Sqlite.SqliteConnection",
        "Mono.Data.Sqlite.SqliteCommand")
    {
    }
    public override bool UseNamedPrefixInParameter {
        get {
            return true;
        }
    }
    public override bool UseNamedPrefixInSql {
        get {
            return true;
        }
    }
    public override string NamedPrefix {
        get {
            return "@";
        }
    }
    public override bool SupportsMultipleOpenReaders {
        get {
            return false;
        }
    }
}

Initially I wanted to derive from the existing SQLiteDriver in nHibernate, but unfortunately the important part is the call to the base constructor on ReflectionBasedDriver, and as SqlLiteDriver hides the constructor of this i can't hook in and provide the three parameters that I need to change. The things changed is the three strings in the constructor call, "Mono.Data.Sqlite" is the assembly where the IDbConnection and IDbCommand implementations are located, and the other two are the names of the implementation. The overridden properties are taken from the existing SqliteDriver in the nHibernate source.

Finally to use our driver we just specify it in our nHibernate configuration

<add key="connection.driver_class" value="Name.Space.MonoSqliteDriver, AssemblyName" />

Conclusion: Extension points are indeed nice, and the stack I use including nHibernate has a lot of them which makes my life a lot easier

OpenRasta talk in Denmark

Jakob Andersen — Mon, 17 Aug 2009 12:14:00 +0200

A few months ago i was in London attending the Progressive .NET conference and listened to Sebastian Lambla present his OpenRasta framework. Not only is Sebastian a great speaker his framework looks really promising. Even though you might not think you are in need of an restful MVC framework there are some interresting opinions build into the framework. So i can only recommend that you attend the Aarhus .NET User Group meeting where Sebastian kindly have agreed to present OpenRasta.

Implementing Generate Constructor refactoring in MonoDevelop

Jakob Andersen — Tue, 28 Apr 2009 22:28:00 +0200

In this post I will cover how to implement a simple generate constructor refactoring in the Open Source .NET IDE MonoDevelop. I have recently started using MonoDevelop because I run linux on my laptop for various reasons, most important one of them is that I miss the power of the commandline and all the small tools that is pretty standard on linux. But the IDE lacks some features and this weekend I decided to dig into the codebase to try to add a few refactorings, this post will cover the first one.

MonoDevelop is build using .NET and the user interface is based on Gtk. So its a little different structure than WinForms but MonoDevelop comes with a nice designer and the application itself contains a lot of UI code you can be inspired by. Im not much of an UI guy myself so I started in the code. The refactorings in MonoDevelop are all registred in the class MonoDevelop.Ide.Commands.CurrentRefactoryOperationsHandler, in this class a methods exists that generate the commands to be available in the Context menu on the currently chosen type, variable, parameter etc:

CommandInfo BuildRefactoryMenuForItem (ProjectDom ctx, ICompilationUnit pinfo, IType eclass, IDomVisitable item, bool includeModifyCommands)
{
    //Implementation
}

The CommandInfo is in its default implementation a single Command but has a specialisation CommandInfoSet that allows us to return multiple commands, so in the implementation of this method we can add several refactorings that is applicable based on the location in code. The parameters passed to the above method is for helping us determine which commands to add and to supply these commands with the information about the code they need to actually perform the refactoring.

ProjectDom contains information about the current project that is a collection of files containing classes etc. refactorings that modify the public interface of the current class needs this to ensure references to the public interface can be updated. A good example of this is the Rename refactoring, if you rename a public property on a class you need to update all references to this with the new name.

ICompilationUnit contains information of the current CompilationUnit which is typically corresponding to the current source file, it contains information about using directives, attributes and types present.

IType references the class if a interface is clicked so, is currently only there to support the "Implement interface" refactoring which needs to know about both the current class and the interface clicked.

IDomVisitable is the type that the user is currently on, that is a class, interface, member, enum etc. this is going to be the most important in our implementation because we only work on a single type and not modifying anything outside this.

includeModifyCommands is a flag that decides whether the CommandInfo's should include refactorings modifying the type. This is useful for not popping up refactorings modifying types we have no control over.

So we need to add logic to the BuildFactoryMenuForItem method to add our refactoring under certain circumstances, more specific when a we have a class marked in the UI, the code for this looks as this:

//Make sure the current item is a type
if(item is IType){ 
    IType type = (IType)item;
    //Make sure that the type is a class and it belongs to a project
    if(type.ClassType == ClassType.Class && type.SourceProject != null){ 
        //Add the command to our CommandInfoSet to be returned (ciset) with its name and a RefactoryOperation delegate
        ciset.CommandInfos.Add("Generate Constructor", new RefactoryOperation(refactorer.GenerateConstructor));
    }
}

As you can see existing code in the method already have initialized the ciset and the refactorer and for simplicity i left out localization of the name of the refactoring. The ciset initialization is pretty straight forward, however the refactorer is interesting: this class contains methods for actually doing the refactoring (or in most cases code that launches the UI that does the refactoring). The refactorer is initialized with pretty much the same parameters as passed to the BuildFactoryMenuForItem:

Refactorer refactorer = new Refactorer (ctx, pinfo, eclass, realItem, null);

Only difference is that we pass realItem instead of our raw IDomVisitable this is because there is some handling of instantiated types and compound types, but that's out of the scope of this post.

The GenerateConstructor method on our refactorer class is pretty simple as all it does is fire up our UI Dialog (which we still need to make):

public void GenerateConstructor(){
    GenerateConstructorDialog dialog = new GenerateConstructorDialog(item);
    dialog.Show();
}

Because we are only manipulating a single class and its contents, and we are only adding new code not modifying existing the only thing we need is the IDomVisitable called item which is the class we need to modify. With just a blank dialog put into this, we have now hooked into the structure of MonoDevelop and added our refactoring to the context menu:

Lets skip the UI part a little while and go to the actual codegeneration. We can utilize the built in code generation features of MonoDevelop namely the class MonoDevelop.Project.CodeGeneration.CodeRefactorer which has a method AddMember(IType cls, System.CodeDom.CodeTypeMember) we already have the IType that we are currently working on passed to our dialog so we need to construct a CodeTypeMember using the System.CodeDom classes.

Ideally we would like to decouple this generation of the CodeTypeMember completely from our UI code, however to keep in line with the style that the rest of MonoDevelop is written we will keep this coupling. However this is definitively a refactoring candidate that should be done throughout MonoDevelop to decouple the actual refactoringcommands from the UI.

I don't wan't to bore you with a lot of UI code so here as a screenshot instead:

We have some basic functionality a five column flat TreeView with the following columns:

a checkbox that decides if the field should be in the constructor
the name of the field
the name of the type
the name of the generated parameter that is editable
a checkbox that decides if an assignment should be generated in the body of the constructor

Furthermore we can sort the order of the parameters and this will be reflected in the generated code. First thing we need to add the fields from the selected type to the TreeView, this is done with the following code:

//Contains our column and the reference to the actual IField
ListStore store = new ListStore(typeof(bool), typeof(string), typeof(string), typeof(string), typeof(bool),typeof(IField)); 
//Add the store to the model of our TreeView
treeview.Model = store;
//Check if the IDomVisitable is actually a class
if(item is IType){
    foreach(IField field in ((IType)item).Fields){
        //Generate a sensible parameter name from the name of the field
        string paramName = GenerateParamName(field.Name);
        //Add the field to our storage with some default values
        store.AppendValues(true, field.Name, field.DeclaringType.Name, paramName, true, field);
    }
}

The code is pretty straight forward, however as mentioned it's not exactly like Windows Forms, but notice the actual MVC approach with us binding the model to the TreeView, actually a very nice way to work with things compared to DataBinding in Windows Forms if you ask me. There is some UI code for generating the columns in the TreeView, handling edits and sorting that i won't post because it is pretty trivial and because this post isn't about programming Gtk. Lastly we should ideally retrieve fields from base types as well that could be initialized and provide them in the list if they are assignable from this type (i.e. protected or public). Lets move on to what happens when we click the OK button and we generate the CodeTypeMember i mentioned before:

//Get the CodeRefactorer from the IDE
CodeRefactorer refactorer = IdeApp.Workspace.GetCodeRefactorer (IdeApp.ProjectOperations.CurrentSelectedSolution);
//Get an iterator for our liststore that backs the TreeView
TreeIter iter;
if(!store.GetIterFirst(out iter))
    return;
//Generate our CodeConstructor from System.CodeDom namespace
var constr = new CodeConstructor();
//Loop over the fields in the store
do {
    //Extract information from store
    bool selected = (bool) store.GetValue (iter, colCheckedIndex);
    IField field = (IField) store.GetValue(iter, colFieldIndex);
    bool genassignment = (bool) store.GetValue(iter, colGenAssignmentIndex);
    string paramName = (string) store.GetValue(iter, colParamNameIndex);
    //Check if the user asked us to include this field as parameter
    if(selected){
        //Generate the parameter and add it to the constructor
        CodeParameterDeclarationExpression param = new CodeParameterDeclarationExpression(field.ReturnType.DecoratedFullName, paramName);
        constr.Parameters.Add(param);
        //Check if the user asked us to generate a default assignment
        if(genassignment){
            //Generate assignment on the form "this.fieldname = paramname" and add to constructor body
            CodeAssignStatement expr = new CodeAssignStatement(
                    new CodeFieldReferenceExpression(new CodeThisReferenceExpression(), field.Name),
                    new CodeVariableReferenceExpression(paramName)
                );
                constr.Statements.Add(expr);
            }else{
                //Generate a TODO comment if param not handled and add to and add to constructor body
                CodeCommentStatement comm = new CodeCommentStatement(string.Format("TODO: Handle parameter {0}", paramName));
                constr.Statements.Add(comm);
            }
        }
} while (store.IterNext (ref iter));
//Lastly use the refactorer to add the generated constructor to the type
refactorer.AddMember((IType)item, constr);

This might seem a bit confusing but actually its not that complicated, a fluent interface around System.CodeDom would certainly make it easier to read. That's basically the code for this refactoring.

There was one single change I had to make to the CodeRefactorer implementation in MonoDevelop because the constructor gets its name from the class, and when using AddMember the class name was hard-coded to be temp when generating the text from the CodeTypeMember, so instead I changed it to take the name from the supplier IType. On a more general note I was very surprised about MonoDevelop, I had expected code of a higher quality and certainly more tests than it has, but that may be the cost of pushing out a pretty feauture complete IDE within a short timeframe.

Gendarme Rule based CIL validation - Building your own rules

Jakob Andersen — Wed, 08 Apr 2009 04:04:44 +0200

Gendarme is a tool for analyzing and finding problems in code in ECMA CIL format (For MS only people out there that is the specification of which MSIL is an implementation). The tool itself comes with a boatload of useful rules to find problems in your code, one example of a rule is ProvideCorrectArgumentsToFormattingMethodsRule this makes sure that every time you call String.Format the number of arguments specified will correspond to the number specified in the format string:

string.Format("{0} would like a cup of {1}", "Jakob");

So the rule would find the above and report it to us when we run our assemblies through Gendarme with that rule chosen. There are a wide array of rules available already but if you feel something is missing either because it is not yet included in Gendarme or perhaps its a rule very specific to a project your working on, you can easily add rules to the framework, that was what it was build for!

Gendarme uses Mono.Cecil to inspect the CLI Image, basically the same as Reflection in Microsoft’s BCL does, and furthermore supports modifying it as Reflection.Emit does. However Reflection and Reflection.Emit only expose a subset of the features of CLI Images whereas Mono.Cecil gives you full access. So the code we are using to inspect and check for our rules is similar in functionality to Reflection code as you know it from MS, however there are some differences.

The first thing to do is to write some tests for the rule we want to create. My idea for a rule is that I would like to avoid getters calling themselves which we all know often is a bad idea. So a simple test class to be used for testing this rule for both success and failures could look like this:

public class Item
{
    public bool UsesItSelf
    {
        get { return UsesItSelf; }
    }

    public bool DoesNotUseItSelf
    {
        get { return false; }
    }
}

Gendarme comes with a bunch of functionality for helping out testing rules in the form of some generic baseclass for our NUnit tests. In our case we want to create a MethodRule (as getters and setters are separate methods in CIL code). So we inherit from MethodRuleTestFixture<T> and get simple functionality to do Assertions on Success or Failure on applying our rule to specific methods. Confused, don't be the test cases are as simple as this:

[TestFixture]
public class UsePropertyGetterInPropertyGetterTest : MethodRuleTestFixture<UsePropertyGetterInPropertyGetterRule>
{
    [Test]
    public void TestUsesItSelf()
    {
        AssertRuleFailure<Item>("get_UsesItSelf");
    }

    [Test]
    public void TestDoesNotUseItSelf()
    {
        AssertRuleSuccess<Item>("get_DoesNotUseItSelf");
    }
}

The generic AssertRuleFailure and AssertRuleSucces takes a generic parameter that tells the type under test and the parameter tells which method should be called. When C# is compiled to CIL code the getters and setters are expanded to two methods with get_ and set_ prefixes in case you didn't know.

Next up we need to implement the actual rule as currently our test cases can't even compile. Our rule needs to be a MethodRule so we need to implement the IMethodRule interface from Gendarme, fortunately a base class called Rule exists which does a lot of the hard work for us already so we inherit from that as well.

[Problem("This property getter calls itself")]
[Solution("It is probably not supposed to, if it is consider refactoring to make it more readable")]
public class UsePropertyGetterInPropertyGetterRule : Rule, IMethodRule
{
    public RuleResult CheckMethod(MethodDefinition method)
    {
        if (!method.IsGetter)
            return RuleResult.DoesNotApply;

        if (!method.HasBody)
            return RuleResult.Success;
        foreach (Instruction instruction in method.Body.Instructions)
        {
            if (instruction.OpCode == OpCodes.Call)
            {
                if(instruction.Operand.ToString() == method.ToString())
                {
                    Runner.Report(method, Severity.High, Confidence.Total);
                    return RuleResult.Failure;
                }
                
            }
        }
        return RuleResult.Success;
    }
}

The only method we implement is CheckMethod, this is called when Gendarme finds a Method and our rule is enabled, so we get the MethodDefinition and need to return a RuleResult. So we take these steps:

1. We check if this is a Getter, if not our rule does not apply

2. We determine the rule it successful if nobody is available (No body = it doesn't call itself)

3. We loop through instructions in the method body and find out if a Call OpCode exists, if it does we compare the method being called with the method we are currently analyzing, if they are the same we return a failure and report this to the Gendarme Runner

That’s it, we have all green lights from our simple test case. We can now use it in the Gendarme tool, either command line, GUI or in your favorite build system. In case of command line usage (and UI I guess) you can add you own assembly containing your own rules to the rules.xml file found in the location you installed Gendarme.

As a last note I would really recommend that you look into the rules bundled with Gendarme, there are a lot of useful ones that could save you a lot of pain if you happen to not have perfect test coverage.

(Be aware that this is meant as an example only of implementing a rule in Gendarme, the above test suite is slim and the code for the actual rule uses some shortcuts that should be eliminated)

Generic pipeline for business objects using Castle Windsor

Jakob Andersen — Sun, 20 Jul 2008 22:01:09 +0200

Currently I'm working with a system handling different operations when receiving business documents in object form. Its quite obvious that the code for handling this has evolved to have a lot more responsibilities than it was intended to.

So already having an Inversion of Control container in our stack I thought we could make the operations in the pipeline configurable using the container. To achieve this we need to specify an interface for the tasks in the pipeline, in our case its pretty simple:

public interface IPipelineTask<T>
{
    T Perform(T instance);
}

Secondly we need to define the pipeline itself, again using a generic interface:

public interface IPipeline<T>
{
    T Execute(T instance);
}

So basically what I want to accomplish is the ability to ask my Inversion of control container for a pipeline for a certain type and be able to call the Execute method on the instance and have all associated tasks performed on the instance I pass to the method. So the code for handling an incoming object of type Invoice would look like this:

Invoice incomingInvoice = ....;
ProjectContainer container = new ProjectContainer();
IPipeline<Invoice> pipeline = container.Resolve<IPipeline<Invoice>>();
Invoice processedInvoice = pipeline.Execute(incomingInvoice);
container.Release(pipeline);

So lets look at the implementation of the generic pipeline that handles executing of each task:

public class Pipeline<T> : IPipeline<T>
{
    private IPipelineTask<T>[] tasks;
    public Pipeline(IPipelineTask<T>[] pipelinetasks)
    {
        tasks = pipelinetasks;
    }

    public T Execute(T instance)
    {
        T processedInstance = instance;
        foreach (var task in tasks)
        {
            processedInstance = task.Perform(processedInstance);
        }
        return processedInstance;
    }
}

Note the constructor takes an array of IPipelineTasks<T> this is here our Inversion of Control container comes to play and does this for us using constructor dependency injection.

Each task needs to implement the IPipelineTask<T> with its specific business object type:

public class InvoiceNotifier : IPipelineTask<Invoice>
{
    private IUserNotifier usernotifier;
    public InvoiceNotifier(IUserNotifier notifier)
    {
        usernotifier = notifier;
    }

    public Invoice Perform(Invoice instance)
    {
        usernotifier.Notify(Notification.IncomingInvoice,
                            "The invoice with identifier " + instance.ID + " changed state to " + instance.State);
        return instance;
    }
}

Normally when working with arrays in Castle Windsor we have to specify each service to be part of the array in the configuration, however in our case we want all registered implementations of the specific interface to be passed to the pipeline. To do this we can add a custom sub dependency resolver to castle, in fact we can use the ArraySubDependencyResolver already written by Castle projects founder (and soon to be Microsoftee) Hammett. With this in place we can make the following configuration and our mission is accomplished and all tasks registered in the configuration will be injected when we request the generic Pipeline of this type.

<components>
   <!--Register the generic pipeline--> 
  <component
    id="bussiness.document.pipeline"
    service="Services.IPipeline`1, Services"
    type="Services.Pipeline`1, Services"
    lifetype="Thread"
    />
   <!--Register our pipeline tasks-->
  <component
    id="invoice.notification"
    service="Services.IPipelineTask`1[[Domain.Invoice, Domain]], Services"
    type="Services.InvoiceNotifier, Services"
    lifetype="Thread"
    />
  <component
    id="invoice.reciever"
    service="Services.IPipelineTask`1[[Domain.Invoice, Domain]], Services"
    type="Services.InvoiceReciever, Services"
    lifetype="Thread"
    />
  
   <!--Registration of services and repositories which our pipeline tasks uses-->
   ....
</components>

Using this infrastructure custom tasks can be specified easily in the configuration even from other namespaces and assemblies. And the pipeline doesn't need to worry about the dependencies of each Pipeline task, the container handles this

Generating DTO's from your fully populated domain classes

Jakob Andersen — Thu, 19 Jun 2008 23:34:11 +0200

When working with object relational mapping(or even handrolled DAL's) you most often work on fully populated objects. When working in an environment utilizing Data Transfer Object either for transport over the wire or screen bound DTO's you have to slice or merge your fully populated objects. With LINQ for nHibernate, LINQ for SQL the solution for this is pretty obvious you populate the object using its constructor or object initialisers in a LINQ query either directly on your data source or on one or more already populated instances.

A quick example using LINQ for nHibernate could be:

var result = from p in db.Products select new ProductDTO {p.ID, p.Name} ;

(Of course we need to make instances not anonymous types because we need to pass them out of the current scope)

If we are stuck using traditional querying in nHibernate we can accomplish the same using HQL:

select new ProductDTO(p.ID, p.Name) from Product p

When using this HQL query its important to remember to import your DTO class in the mapping or else you will end up with an error like:

NHibernate.QueryException : class not found: ProductDTO

To import it just add <import class="Name.Space.ProductDTO, Assembly"> right after your hibernate-mapping element. Of course the generating of the DTO's can get much more complex than the samples i have shown. They could span multiple business object requiring complex queries but the concept remains the same.

Okay, so these options are valid only for folks using an LINQ empowered ORM's or frameworks with equivalent functionality to the nHibernate sample above. One thing we could do is to create the DTO's from the fully populated objects. Of course this could be a dangerous decision if you don't already have the objects in the current context and the DTO's require a very little subset of the data, so that's definitely worth noting. That beeing said we could do this in a number of ways all which i can thing of writing myself involves plumbing code. So a couple of days ago I stumbled upon a project called otis a object transformer or Object-to-Object mapper if you prefer that term.

The concept is pretty simple, we can define how one object map to another so if we take our very simple case we can specify a mapping on this form:

<?xml version="1.0" encoding="utf-8" ?>
<otis-mapping xmlns="urn:otis-mapping-1.0">
  <class name="Name.Space.ProductDTO, Assembly" source="Name.Space.Product, Assembly" >
    <member name="ID" />
    <member name="Name" />
  </class>
</otis-mapping>

In the above case we have the same names on properties in both classes so its pretty simple, but the possibilities in the mapping is many. You can use expression to combine multiple values to one, projections, exchanging certain values etc. I will certainly have to look into the source code of otis and have a look of its capabilities as the documentation is a bit sparse.

To utilize the above mapping we configure the framework and use a generic class to get Assembler classes that can convert our types, its pretty simple:

Product product = ...; //Our fully populated product instance
Otis.Configuration conf = new Otis.Configuration();
//Looks for embedded ressource with *.otis.xml ending
conf.AddAssemblyResources(Assembly.GetExecutingAssembly(), "otis.xml"); 
//Declare our assembler
var asm = conf.GetAssembler<ProductDTO, Product>();
//Use the assembler to get the DTO
ProductDTO dto = asm.AssembleFrom(product);

As I said I will definitely dive into the source to explore which features are available and how the transformation is done and what the costs of it is. The main issue I have with the approach is that we could do the same using code and to make it more flexible lambda expressions and have it strongly typed and avoid the verbosity of XML, but lets see how feature rich Otis is before dismissing it.

Copenhagen .NET User Group - Startup

Jakob Andersen — Fri, 13 Jun 2008 13:40:14 +0200

A .NET User Group is starting up in Copenhagen for more information check http://cnug.dk/ (in Danish). I Hope to see many of the Danish developers on the 19th of June in Ballerup. Its gonna be a talk about expectations for the User Group and a presentation of some concepts from object relational mapping.

Why the database should handle paging

Jakob Andersen — Fri, 06 Jun 2008 01:45:26 +0200

Notice that the scrollbar isn't at the bottom. That's a lot of data to fetch if you only show a single page of them

(click for larger image)

Generating passwords

Jakob Andersen — Tue, 03 Jun 2008 23:38:32 +0200

So if you need to generate passwords easy you don't have to reinvent the wheel, you can use functionality that the Mempership functionality from ASP.NET already has. On the Membership class in System.Web.Security namespace is a static method for generating passwords. You can specify a length and how many non alphanumeric characters it should contain.

Of course its not exotic in anyway and you can not control the set of characters used (apart from how many should be non alphanumeric) and it does not generate pronounceable passwords.

string password = Membership.GeneratePassword(7, 1);

The above code will generate a string with seven random characters. Its worth taking note of the second parameter. It specifies the minimum number of non-alphanumerical characters so the generated password can contain more than one in the above case.

If you need to generate pronounceable passwords I would recommend you take a look at the C implementation available here: http://www.multicians.org/thvv/tvvtools.html#gpw it covers the theory behind using trigraphs and furthermore shows implementation of how to extract trigraphs from a dictionary and how to use this to generate the actual passwords.

But to keep it short, if you just need a random set of chars. Use the features already in the framework instead of rolling your own! The lines saved makes fewer lines that could contain that tricky bug you are hunting a few months from now.

Common nHibernate exceptions and a question

Jakob Andersen — Tue, 13 May 2008 16:27:46 +0200

I often get asked question about nHibernate issues the question discussed last in this post is often brought up. But lets start out with a few simple exceptions that can sometimes take up more of your time than you would like.

"NHibernate.MappingException : Unknown entity class: MyNamespace.With.Persistent.Class"

You are trying to use a class as persistent that nHibernate wouldn't know how to handle. The number one reason for this error is that you have mapping files as embedded resources and that you forgot to actually embed the mapping file.

"NHibernate.MappingException : persistent class ClassName not found" or "NHibernate.MappingException : associated class not found: ClassName"

This is usually an error in your mapping, nHibernate can't find the class you reference in your mapping. This is often caused by typos or missing to specify in which assembly or namespace your persistent class is to be found. You can specify a default assembly and namespace in the <hibernate-mapping> element or you can write the name of your classes with the assembly and namespace specified on the form "Namespace.ClassName, Assembly".

"NHibernate.InvalidProxyTypeException : The following types may not be used as proxies"

This is a classic, if you want to use nHibernates lazyloading features you need to specify your classes properties as virtual so nHibernate can create proxies for you. If you don't need to use lazyloading on specific type mark these types with lazy="false" in the class element, and you won't have to mark its properties as virtual.

So that's a handful of the most common exceptions when starting out with nHibernate. Lets move on to a question I have answered quite a few times. People often want to minimize the number of roundtrip's to the database by joining and retrieving larger resultsets and have nHibernate transform this larger set of results into the correct object graph. Whether this is a good optimization depends heavily on the expected data since it could result in a huge amount of redundant data transferred between database and application. But nonetheless the thing that often tricks people is illustrated by the following test:

//Assumme we have 2 invoices with 3 invoicelines each
IList<Invoice> invoices = s.CreateCriteria(typeof (Invoice)).SetFetchMode("InvoiceLines", FetchMode.Join).List<Invoice>();
Assert.AreEqual(2, invoices.Count);

This test will fail, because you actually get 6 invoice entities back. That's because the resultset contains duplicate invoices (one for each InvoiceLine) and nHibernate transforms these into invoice instances. One way to fix this is to specify that you want distinct root entities back. This is done by specifying a result-transformer like this:

IList<Invoice> invoices =
                s.CreateCriteria(typeof (Invoice)).
                SetFetchMode("InvoiceLines", FetchMode.Join).
                SetResultTransformer(CriteriaUtil.DistinctRootEntity).
                List<Invoice>();

So what if your data isn't suitable for joining, you might end up with the large resultset I mentioned earlier? And we don't want to hit the N+1 Select problem by selecting the InvoiceLines for each of the fetched Invoice's. That's were nHibernates batch fetching can be used. We have retrieved all the Invoices we want to use and afterwards we want to select the invoicelines for those. We can specify that our InvoiceLines should be retrieved in batches by specifying a batch-size on the collection in our mapping file.

<set name="InvoiceLines" batch-size="20">
	<key column="InvoiceID" />
	<one-to-many class="InvoiceLine" />
</set>

I just used 20 as an example, this means that nHibernate will fetch the InvoiceLines for 20 Invoices at a time. So this will result in two roundtrip's(in our example case), and this without fetching duplicate data in the resultsets. You could optimize some scenarios like the one above using MultiQuery or MultiCriteria, that is sending multiple queries in one roundtrip, but that's another story.

BlogEngine.NET - Urlrewriting

Jakob Andersen — Thu, 08 May 2008 13:40:59 +0200

So the first thing I usually do when reviewing web projects is to find the default entry page that the user would see. When doing this with BlogEngine.NET you find the default.aspx (obviously in most cases). The first thing in the Page_Load of this is the following code:

if (Request.RawUrl.ToLowerInvariant().Contains("/category/")){...}
else if (Request.RawUrl.ToLowerInvariant().Contains("/author/")){...}
else if (Request.RawUrl.ToLowerInvariant().Contains("?tag=")){...}
//a couple of else if's more

So this makes it clear that the default.aspx page handles all listing of posts whether it is all in a category, all by an author or all having a specific tag. All these listings are requested using different URI's, to handle this an UrlRewrite HttpModule is implemented. If we look at some code in this UrlRewriter we will find:

if (context.Request.Path.Contains("/blog.aspx")){...}
else if (url.Contains("/POST/")){...}
else if (url.Contains("/CATEGORY/")){...}
else if (url.Contains("/AUTHOR/")){...}
//a couple of else if's more

So what happens here is we delegate the responsibility for different URL's to be handled on different pages, the responsibilities redirected to the default page is afterwards on the default page once again delegated to different methods handling databinding because presentation is alike. This results in some parsing of the URL's is duplicated in the UrlRewriter and in the default.aspx.cs file. And furthermore the collection of all posts is iterated both in the UrlRewriter and on the pages, that seems silly. Why not let UrlRewriting do what its intended for: to forward information and then keep the processing on simple pages for specific requests to avoid the redundant parsing and iteration?

I read an interview with the BlogEngine.NET founder on InfoQ a while back, and it seems he has some issues with third party dependencies. I don't see the reason for this, if you can use a third party dependency too do a task it does well and have been doing in many projects already, why roll your own. So allow me to introduce UrlRewritingNet.UrlRewrite

UrlRewritingNet basically consists of a generic HttpHandler that rewrites based on rules you set up in a configuration section in your web.config file, so instead of having to change code to change rewrites, we change simple regular expressions in our configuration of UrlRewritingNet. So lets see the rules I set up for BlogEngine.NET:

<configSections>
	<section name="urlrewritingnet"
		restartOnExternalChanges="true"
		requirePermission="false"
		type="UrlRewritingNet.Configuration.UrlRewriteSection, UrlRewritingNet.UrlRewriter"
	/>
</configSections>
<urlrewritingnet xmlns="http://www.urlrewriting.net/schemas/config/2006/07">
	<rewrites>
		<add name="categoryRule" virtualUrl="^~/category/(.*).aspx" destinationUrl="~/category.aspx?name=$1"/>
		<add name="blogRule" virtualUrl="^~/blog.aspx" destinationUrl="~/default.aspx?blog=true"/>
		<add name="authorRule" virtualUrl="^~/author/(.*).aspx" destinationUrl="~/author.aspx?name?=$1"/>
		<add name="postRuleDate" virtualUrl="^~/post/(\d{4})/([0-1]?\d)/([0-3]?\d)/(.*).aspx"
			destinationUrl="~/post.aspx?year=$1&amp;month=$2&amp;day=$3&amp;name=$4"/>
		<add name="postRuleMonth" virtualUrl="~/post/(\d{4})/([0-1]?\d)/(.*).aspx"
			destinationUrl="~/post.aspx?year=$1&amp;month=$2&amp;name=$3"/>
		<add name="postRuleTitle" virtualUrl="~/post/(.*).aspx" destinationUrl="~/post.aspx?name=$1"/>
		<add name="pageRule" virtualUrl="~/page/(.*).aspx" destinationUrl="~/page.aspx?name=$1"/>
		<add name="calendarRule" virtualUrl="~/calendar/.*" destinationUrl="~/calendar.aspx"/>
	</rewrites>
</urlrewritingnet>
<system.web>
	<httpModules>
		<add name="UrlRewriteModule" type="UrlRewritingNet.Web.UrlRewriteModule, UrlRewritingNet.UrlRewriter"/>
	</httpModules>
</system.web>

The above handles rewriting of Url's nothing more, nothing less. The existing BlogEngine.NET UrlRewrite have some business logic built in, for instance to retrieve the identifier of posts and sending them to the page that shows the post. I feel this doesn't belong in an UrlRewriter so I will implement this logic on the pages that actually handles the requests instead of on the UrlRewriter.

So this was the first step, now we can move the if statement out of our default.aspx and let it concentrate on showing the default content which is the frontpage of the blog and the other pages concentrate on their tasks. How to implement the pages referred to in the mapping above will follow in the next post.

Small challenge: call method on null

Jakob Andersen — Fri, 25 Apr 2008 00:31:34 +0200

Inspired by some talk I "overheard" on twitter I thought it would be interesting to post a small challenge. Is it possible to implement the missing parts of the following code so it compiles and runs without exceptions, if yes how would you do it? You are not allowed to modify the body of the Main method but the rest is up to you.

static void Main(string[] args)
{
    Foo f = null;
    f.Bar();
}

And yes its a pretty useless exercise :-)

BlogEngine.NET - DAL Architecture

Jakob Andersen — Thu, 24 Apr 2008 23:45:35 +0200

So as I wrote a few days ago I have been looking at BlogEngine.NET and considered how I would have designed its lower layers. So lets kick off with the provider that's currently used in BlogEngine.NET for accessing the various storages (XML and RDBMS). The provider is responsible for accessing all data, that is Pages, Categories, Posts etc. Furthermore for each of these types of data it is responsible for the structure of the storage location, transforming the data from storage to objects including loading of related data. In my book this isn't good for extensibility, and as BlogEngine.NET provides multiple point for extending its functionality I would argue that it should be possible to extend its storage mechanism to handle new types of data just as easily. Currently extending the data access would involve adding new members to the provider and its implementations.

So to solve this problem (and a few others I will address shortly) my suggestion would be to make data access classes responsible for a single type only, these can share some common functionality that deals with the structure of the storage when we talk about the XML provider. So basically we want to specify how these classes should look, the most generic approach is represented by this interface.

public interface IRepository<T>
{
    //Retrieval
    T Load(Guid identifier);
    IList<T> LoadAll();

    //Modification
    void Save(T instance);
    void Delete(T instance);
    void Delete(Guid identifier);
}

I have made the assumption here that all data has a Guid identifier, of course this could be handled so that we are free to choose the type of our identifier. But for know im satisfied with the Guid-identifier

Instead of implementing our repositories right away we can abstract common details for storage types away in abstract classes. This way the implementation of our actual repositories are as slim as possible. I have (based on the way XML is stored in BlogEngine.NET) chosen two different storage types for XML and implemented the abstract classes SingleFileRepository<T> and SingleFolderRepository<T>. The first one handles storage of data types where all instances are in a single XML file, the second one handles storage of data types where each instance has its own XML file all contained in a folder. So the basic responsibility of these two classes is to handle details of the storage, that is the structure on disk and the structure in the files. Let me remind you that these abstract classes are only for simplifying the implementation of the actual repositories, if development later requires changing minor details we can override or even change the implementations on these, and if we want to start from scratch without the assumptions build into these abstract classes we can implement IRepository<T> any way we would like. This gives great flexibility in how different data is stored and the opportunity for code reusability is very much still there.

Lets take a look at the code for SingleFolderRepository:

public abstract class SingleFolderRepository<T> : IRepository<T> where T : class, IEntity
{
    protected readonly IBlogSettings settings;
    protected readonly IObjectXmlConverter<T> converter;
    protected readonly string storagelocation;

    public SingleFolderRepository(IBlogSettings settings, IObjectXmlConverter<T> converter)
    {
        this.settings = settings;
        this.converter = converter;
        this.storagelocation = settings.StorageLocationFor(typeof (T));
    }

    public T Load(Guid identifier)
    {
        string path = Path.Combine(storagelocation, identifier + ".xml");
        FileInfo datafile = new FileInfo(path);
        if (datafile.Exists)
        {
            return converter.Build(GetXml(datafile));
        }
        return null;
    }

    private string GetXml(FileInfo datafile)
    {
        string xml = string.Empty;
        using (StreamReader sr = new StreamReader(datafile.Open(FileMode.Open, FileAccess.Read, FileShare.Read)))
        {
            xml = sr.ReadToEnd();
        }
        return xml;
    }

    public IList<T> LoadAll()
    {
        List<T> instances = new List<T>();
        DirectoryInfo datadirectory = new DirectoryInfo(storagelocation);
        if (datadirectory.Exists)
        {
            foreach (FileInfo datafile in datadirectory.GetFiles("*.xml"))
            {
                instances.Add(converter.Build(GetXml(datafile)));
            }
        }
        return instances;
    }

    public void Save(T instance)
    {
        if (converter.IsNew(instance))
        {
            instance.Identifier = Guid.NewGuid();
        }

        string path = Path.Combine(storagelocation, instance.Identifier + ".xml");
        using (FileStream fs = File.Open(path, FileMode.Create, FileAccess.Write, FileShare.None))
        {
            using (StreamWriter writer = new StreamWriter(fs))
            {
                writer.Write(converter.Flatten(instance));
                writer.Flush();
            }
        }
    }

    public void Delete(T instance)
    {
        Delete(instance.Identifier);
    }

    public void Delete(Guid identifier)
    {
        string path = Path.Combine(storagelocation, identifier + ".xml");
        File.Delete(path);
    }
}

So notice the constructor. The dependencies that this class has is passed into the contructor so before we can use the repository we need settings for the blog and an IObjectXmlConverter for the type that the repository handles. The IObjectXmlConverter handles flattening of objects to XML and building objects from XML. Below is an example an implementation of this.

public class CategoryConverter : IObjectXmlConverter<Category>
{
    public Category Build(string xml)
    {
        XmlDocument doc = new XmlDocument();
        doc.LoadXml(xml);
        Category c = new Category();
        c.Identifier = new Guid(doc.SelectSingleNode("/category/").Attributes["id"].InnerText);
        c.Name = doc.SelectSingleNode("/category/").InnerText;
        return c;
    }

    public string Flatten(Category instance)
    {
        return
            XmlOutput.Create().XmlDeclaration()
                .Node("category")
                .Attribute("id", instance.Identifier.ToString())
                .InnerText(instance.Name).GetOuterXml();
    }
}

So this is where the mapping between the datastore and the objects happen, of course error handling should be in place here if we expect missing values in the data we load.

With this change in structure presented above we have seperated concerns of the data access into smaller reusable components, furthermore in my book this makes the code easier to extend and understand but thats a subjective matter.

So now its time to specify the actual repositories, we could settle for the functionality present on our generic IRepository but often we want more specific functionality for each datatype for instance fetching all posts in a specific category, paging of posts and so forth. So for each data type we define an interface with its actions. Currently in BlogEngine.NET much of this functionality is done in various places for instance sorting, filtering and paging. I would like to have our repositories responsible for this because the most efficient way to do these things depends on the type of storage. That is paging would for instance be done different for XML storage and RDBMS storage.

So as an example we could make our repository for posts have an interface like this:

public interface IPostRepository : IRepository<Post>
{
    PageableList<Post> GetPage(int pagesize, int pagenum);
    PageableList<Post> GetPageInCategory(int category, int pagesize, int pagenum);
    PageableList<Post> GetPageWithTag(int tag, int pagesize, int pagenum);
    PageableList<Post> GetPageFromMonth(int month, int year, int pagesize, int pagenum);
}

Notice that we might need more methods, but this illustrates some examples on how we let the repository handle paging so it can optimize it based on the data storage.

The actual implementation in the XML storage can be optimized but for now we load all data and do it in memory like BlogEngine.NET currently does. (I will discuss caching in a later post)

The form and responsibility of our repositories is now pretty clear. You might have noticed that I have passed classes dependencies through their constructor. To avoid having to construct these dependencies myself I will use an Inversion of Control container that manages these dependencies for me. Furthermore configuration of the IoC container is what helps use interchange the repositiores for XML and RDBMS.