Blogo.NET in action

It's been a few months now since I released Blogo.NET, an ASP.NET version of my blogging engine. Since I've published it, I've gotten great feedback: compliments, feature requests and questions about the chosen architecture.

As I have other projects to work on and Blogo.NET is not officially supported, I will not implement a new version or any patches, I'll leave it to others to use it as a base and improve it. However, I do want to clear a common issue concerning the architecture.

In the Blogo.NET architecture, LINQ is used as the ORM layer. On top of LINQ is a custom DAL (Data Access Layer), This DAL layer consists of classes that mirror the LINQ classes. They provide common data access methods, such as GetItem, GetList, Save and Delete. So far, so good.

Next in the Blogo.NET architecture is the BL (Business Layer). This layer uses the DAL to interact with the data. The purpose of this layer is to seperate business logic from data access. However, for a simple application like Blogo.NET that contains little business logic, this is cumbersome. The BL classes are in essence stub classes with identical methods as the DAL classes. Thus, if you would change anything in the database definition, you would have to update both the DAL and BL classes. 

Many have spotted this issue. Although they somewhat like the architecture, they find it somewhat impractical for small applications like Blogo.NET. Luckily, there is a simples solution: partial classes. Simply create a class with the same name as the LINQ class. As an example, we'll use the "tag" class of Blogo.NET:

namespace DAL
{
    public partial class tag
    {
        public string return_name()
        {
            return "this tag was used: " + tagname;
        }
    }
}

Notice how the above class is named identical to the LINQ class and how it is marked partial. In this class you would typically code your custom business logic for the tag class. In this example, I only added a simple custom method to return the tagname. Notice how our custom class does not even have a tagname property. Since this is a partial class, it will use the tagname property of the LINQ tag class.

Simple, isn't it? Code your custom business logic in the custom partial class, use the generated LINQ tag class for data access. From the outside, they are compiled as a single class that has both the custom business logic methods and the data access methods. Another advantage of a partial class is that when you change your LINQ mapping, the custom code is not overwritten. 

I hope this clarifies how you can use a lighter, alternative architecture in ASP.NET/LINQ apps.

RATE THIS CONTENT (OPTIONAL)

	Was this document useful to you?
	Rating:	Awesome  Good  Average  Poor  Useless

CREATE A NEW COMMENT

	Name:
	Email:
	Website:
	Content:	HTML is not allowed. Hyperlinks will automatically be converted.