Every now and then I get to doing something just because... well, because I can. These projects usually atrophy before becoming anything usable and serve more as a way to explore and practice than anything else. Usually. My latest tangent actually got to a state where I can let it loose in the wild and it’ll probably actual do what it is supposed to do.
Let me be perfectly clear up front: I don’t actually use BlogEngine.Net at all. Anywhere. I’m still a Subtext guy when it comes to blogging software. BlogEngine.Net still lacks critical features and that prevents me from using it as yet (primarily running multiple blogs from a single installation/database).
That said, BlogEngine.Net is a lovely little product with a lot to like about it. The extensibility model is extremely easy to use and flexible. The theming doesn’t suck. And its architecture is easy to navigate/understand even while it makes investments in areas I consider likely to payoff.
While I like the product, the data access bugs me more than a little. It uses a provider model and includes built-in XML and database providers. These are good things. For flexibility, the database provider uses System.Data.Common and the DbProviderFactory with string-built commands. This structure allows BlogEngine.Net to be able to use any database that has a .Net data provider (including things like MySQL, SQLite, or VistaDB). Incidentally, they downplay (unintentionally?) this feature on their website saying in their FAQ that they support XML and “the SQL Server provider”.
At any rate, here’s their SelectPage implementation as an example
public override Page SelectPage(Guid id)
Page page = new Page();
string connString = ConfigurationManager.ConnectionStrings[connStringName].ConnectionString;
string providerName = ConfigurationManager.ConnectionStrings[connStringName].ProviderName;
DbProviderFactory provider = DbProviderFactories.GetFactory(providerName);
using (DbConnection conn = provider.CreateConnection())
conn.ConnectionString = connString;
using (DbCommand cmd = conn.CreateCommand())
string sqlQuery = "SELECT PageID, Title, Description, PageContent, DateCreated, " +
" DateModified, Keywords, IsPublished, IsFrontPage, Parent, ShowInList " +
"FROM " + tablePrefix + "Pages " +
"WHERE PageID = " + parmPrefix + "id";
cmd.CommandText = sqlQuery;
cmd.CommandType = CommandType.Text;
DbParameter dpID = provider.CreateParameter();
dpID.ParameterName = parmPrefix + "id";
dpID.Value = id.ToString();
using (DbDataReader rdr = cmd.ExecuteReader())
page.Id = rdr.GetGuid(0);
page.Title = rdr.GetString(1);
page.Content = rdr.GetString(3);
page.Description = rdr.GetString(2);
page.DateCreated = rdr.GetDateTime(4);
page.DateModified = rdr.GetDateTime(5);
page.Keywords = rdr.GetString(6);
page.IsPublished = rdr.GetBoolean(7);
page.IsFrontPage = rdr.GetBoolean(8);
page.Parent = rdr.GetGuid(9);
page.ShowInList = rdr.GetBoolean(10);
I want to reiterate that I’m not ripping on their choice to use this data access methodology. If you want the flexibility to use any .Net supported data provider without a third-party dependency, this is how you get it. You could optimize some of the stringiness, but with trade-offs.
Linq, Linq, Baby
That said, I don’t mind being tied to SQL Server and if I’m going to muck with the data layer (like, say, if I’m going to attempt multiple blogs from a single application instance) I want something simple that I can use without all that extra goo. I looked for any hint that this might have been done already, but I couldn’t find anything. It looks like I’m the only one with this particular manifestation of brain damage.
Since configurable table prefixes are a desirable feature and since that’s easier to do in Linq to SQL I figured it’d be best to go that route. It was good to get the table prefix stuff into a working project and have it work about as I expected it to.
Implementing the BlogEngine.Net blog provider turns out to be pretty easy in Linq. Ditto the Role and Membership providers. I tried to stay as close as possible to the DbBlogProvider. Even so, I found that some of the admin components are picky enough that even little things could bite me (the category editing page blows up if you leave category descriptions null, for example).
For compare and contrast, here’s my SelectPage method using Linq to SQL
public override Page SelectPage(Guid id)
Page page = null;
using (Data.BlogDataContext context = getNewContext())
Data.Page pageData = (from p in context.Pages
where p.PageID == id
if (pageData != null)
page = new Page()
Id = pageData.PageID,
Title = pageData.Title,
Description = pageData.Description,
Content = pageData.PageContent,
Keywords = pageData.Keywords,
DateCreated = pageData.DateCreated.HasValue ? pageData.DateCreated.Value : DateTime.MinValue,
DateModified = pageData.DateModified.HasValue ? pageData.DateModified.Value : DateTime.MinValue,
IsPublished = pageData.IsPublished.HasValue ? pageData.IsPublished.Value : false,
IsFrontPage = pageData.IsFrontPage.HasValue ? pageData.IsFrontPage.Value : false,
Parent = pageData.Parent.HasValue ? pageData.Parent.Value : Guid.Empty,
ShowInList = pageData.ShowInList.HasValue ? pageData.ShowInList.Value : false
BlogEngine.Net for SQL Server
So I got the thing working and thought I’d open it for “the community”. Since BlogEngine.Net is on CodePlex, that was a natural choice. Anyone sharing my peculiar proclivity is invited to head on over, take a poke and let me know what can change for the better. Or better yet, submit a patch. Or better, better yet, join the project. (also: CodePlex’s recent transparent svn compatibility is awesome! When did that happen?)
If you do poke at the project, some forewarning. First, I don’t have unit tests for this and don’t plan on any (I’m not against using them, I just don’t want the headache of creating them myself). Data access is more in the realm of “integration testing”, so I’m not sure there’s much you can really do that’s actually useful. It might be different if BlogEngine.Net had a suite of tests I could use to validate my providers against, but...
Second, I haven’t gone out of my way to do a lot of commenting. This is deliberate. These methods are short, should be self-explanatory, and since they should be hidden behind a provider I didn’t even bother with the typical XDoc stuff. Anything directly accessing them such that intellisense comes to bear is doing something wrong...
Room to Improve
In the end, this is the ground-work to remove an (admittedly trivial) barrier in working with BlogEngine.Net. I hope to help move as much as possible into the database in order to support things like multi-blog configurations. BlogEngine.Net hasn’t been very disciplined in its storage layer and XML really is the default medium. Things like referrer tracking don’t use a provider at all so you really can’t (yet) get away from XML files in your App_Data directory (and hence, read/write permission configuration). Since I want that to change, I’m going to see if I can’t get that going a bit.
Things to do
- Decide on a database update methodology (so far, I’m using the already-existing tables and hence piggy-backing on the BlogEngine.Net scripts)
- Replace the built-in ReferrerModule (use/create provider model access for referrers?)
- Comb the project for any other errant XML dependencies
- Work on multi-blogging configuration