sorted by: recent | see : popular

Content Tagged with tag4sree + blogengine.net

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.

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.

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.

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.

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.

Last Friday I took a look at the source code from BlogEngine.NET I wrote a little log during my short look:

20:32 - Downloaded the latest source from BlogEngine.NET on codeplex
20:34 - Build the solution and starting the website after a single problem with the website expected in another place than I put it
20:37 - Examining the file format of posts and settings. All is stored in XML as default, but there should be a possibility to use a database.
20:39 - How is data loaded. Data is loaded using a provider, the base provider is BlogProvider and the provider handling loading of posts from Xml is called XmlBlogProvider
20:40 - "Back to the future" starts in TV, long time since last seen so it is running in the background :-)
20:55 - Browsed around the source finding things like pingback code, Widgets, Extensions, MetaWeblog API.
20:56 - UI parts. Layouts is handled with themes placed in the themes folder, these consist of a Masterpage file, CommentView and PostView user-controls. The masterpage is applied in the OnPreInit method on every page that inherits from BlogBasePage. The two controls CommentView and PostView are initiated based on folder structure and loaded using LoadControl method.
21:06 - Time for a focusing on "Back to the future" and leave BlogEngine.net alone

Aside from demonstrating my very short attention span I actually made some impressions about the source. So allow me to jump the gun and summarize my points about the code even though I haven't investigated it thoroughly. So feel free to correct(or bash) me if you feel I'm either unfair or wrong.

Blogengine.NET is a relatively small project in terms of lines of code, having estimated 20000 LoC (Anyone knows a good tool to get these metrics when using VS Professional 2008). the data access layer is based on the provider model which we know from ASP.NET. Fortunately the providers in BlogEngine.NET doesn't suffer from the same flaw as in ASP.NET: they are neither sealed or have internal members. However one thing puzzles me, the XmlBlogProvider class is scattered across 8 files using the partial class features and contains approximately 900 LoC. The same goes for the MSSQLBlogProvider class which contains 1100 LoC contained in a single file.  In both cases I feel that the data access could be separated in parts that handle a more specific concern than its the case currently.

A funny detail is that the chosen provider is wrapped in an Service class with static methods that expose roughly the members existing on the provider. This service class has 27 members all carefully ensuring that they call the LoadProviders method before doing anything, it seems that a static constructor could have saved these 27 calls and the possibility of an error if a developer forgets to call the method in a new member.

Another thing that I found quite odd, is the way posts are cached to avoid hitting the storage. Regardless of the provider used, all post(including their comments) are stored in a static collection found on the Post business class. For most installations this results in a memory footprint of limited size but an effort is going on to support multiple blogs on a single installation so this strategy could be expensive memory-wise. Furthermore a lot of CPU cycles is used when the Blog instances need to get posts from a single month or posts that has a specific tag because these are filtered in memory.

If we turn our eyes at the core business classes of the solution they are communicating with the BlogService for retrieval of data etc. It could reassemble an ActiveRecord pattern but the implementation of the data access code is mingled with the actual code of the business object and not separated.

All business classes inherit from a generic base class called BusinessBase. A lot of code is in this base class (500+ LoC) and it seems a lot of it is never used. One example of this is the equal and not equal operators which are overloaded for BusinessBase but never seems to be used in the solution. Validation and ChangeTracking is handled in the base class as well. It seems strange why we would need ChangeTracking as the persistence mechanism isn't using a unit of work pattern. And in fact the change tracking isn't used for anything else than aborting a save request if the object hasn't changed. In my opinion this is not keeping it simple as i always thought the BlogEngine.NET philosophy was.

I know what you're thinking now, its easy to be a party pooper. And yes it is easy to be critical about a codebase when you don't have to supply a better solution and that's the reason that this post haven't been published before today (A week after I wrote most of it). I have used a couple of hours during the week to think about architecture in the lower layers in BlogEngine.NET and have implemented them, more about my approach will follow over the next days.

Last Friday I took a look at the source code from BlogEngine.NET I wrote a little log during my short look:

20:32 - Downloaded the latest source from BlogEngine.NET on codeplex
20:34 - Build the solution and starting the website after a single problem with the website expected in another place than I put it
20:37 - Examining the file format of posts and settings. All is stored in XML as default, but there should be a possibility to use a database.
20:39 - How is data loaded. Data is loaded using a provider, the base provider is BlogProvider and the provider handling loading of posts from Xml is called XmlBlogProvider
20:40 - "Back to the future" starts in TV, long time since last seen so it is running in the background :-)
20:55 - Browsed around the source finding things like pingback code, Widgets, Extensions, MetaWeblog API.
20:56 - UI parts. Layouts is handled with themes placed in the themes folder, these consist of a Masterpage file, CommentView and PostView user-controls. The masterpage is applied in the OnPreInit method on every page that inherits from BlogBasePage. The two controls CommentView and PostView are initiated based on folder structure and loaded using LoadControl method.
21:06 - Time for a focusing on "Back to the future" and leave BlogEngine.net alone

Aside from demonstrating my very short attention span I actually made some impressions about the source. So allow me to jump the gun and summarize my points about the code even though I haven't investigated it thoroughly. So feel free to correct(or bash) me if you feel I'm either unfair or wrong.

Blogengine.NET is a relatively small project in terms of lines of code, having estimated 20000 LoC (Anyone knows a good tool to get these metrics when using VS Professional 2008). the data access layer is based on the provider model which we know from ASP.NET. Fortunately the providers in BlogEngine.NET doesn't suffer from the same flaw as in ASP.NET: they are neither sealed or have internal members. However one thing puzzles me, the XmlBlogProvider class is scattered across 8 files using the partial class features and contains approximately 900 LoC. The same goes for the MSSQLBlogProvider class which contains 1100 LoC contained in a single file.  In both cases I feel that the data access could be separated in parts that handle a more specific concern than its the case currently.

A funny detail is that the chosen provider is wrapped in an Service class with static methods that expose roughly the members existing on the provider. This service class has 27 members all carefully ensuring that they call the LoadProviders method before doing anything, it seems that a static constructor could have saved these 27 calls and the possibility of an error if a developer forgets to call the method in a new member.

Another thing that I found quite odd, is the way posts are cached to avoid hitting the storage. Regardless of the provider used, all post(including their comments) are stored in a static collection found on the Post business class. For most installations this results in a memory footprint of limited size but an effort is going on to support multiple blogs on a single installation so this strategy could be expensive memory-wise. Furthermore a lot of CPU cycles is used when the Blog instances need to get posts from a single month or posts that has a specific tag because these are filtered in memory.

If we turn our eyes at the core business classes of the solution they are communicating with the BlogService for retrieval of data etc. It could reassemble an ActiveRecord pattern but the implementation of the data access code is mingled with the actual code of the business object and not separated.

All business classes inherit from a generic base class called BusinessBase. A lot of code is in this base class (500+ LoC) and it seems a lot of it is never used. One example of this is the equal and not equal operators which are overloaded for BusinessBase but never seems to be used in the solution. Validation and ChangeTracking is handled in the base class as well. It seems strange why we would need ChangeTracking as the persistence mechanism isn't using a unit of work pattern. And in fact the change tracking isn't used for anything else than aborting a save request if the object hasn't changed. In my opinion this is not keeping it simple as i always thought the BlogEngine.NET philosophy was.

I know what you're thinking now, its easy to be a party pooper. And yes it is easy to be critical about a codebase when you don't have to supply a better solution and that's the reason that this post haven't been published before today (A week after I wrote most of it). I have used a couple of hours during the week to think about architecture in the lower layers in BlogEngine.NET and have implemented them, more about my approach will follow over the next days.