BlogEngine is an asp.net 2.0 application. As the name suggests it is for people that want a blog site.
As a blog, BlogEngine is quite good. It provides the expected features: content postings (duh), comments, RSS/ATOM feed(s), archives, tagging, categorization, etc. It has a slew of extras like “gravatars”, content ratings, support for coComment, DZone, KickIt, and del.icio.us. And of course, BlogEngine takes care of pingbacks, trackbacks, custom tracking, endorsement (bLink), etc too. The new version also has multi-author support, comment moderation, and several other nice touches.
In short, it does what a blog should do, and it does most of that very well.
Despite the name though, this is not really an “engine” in the classic software definition of the word. Part of the application could be described as an “engine” but it isn’t well designed for use within other applications. There are two source assemblies, one for the web site itself and the other is a class library. But the class library has some tight coupling and a reliance on the hosting asp.net web context.
The class-library contains the HttpHandlers and HttpModules that the web site uses to process the incoming requests. These don’t seem to really belong in the class library since they have questionable value to other web applications that might want to use the class library and would have no value at all in a non-web application. The class library also contains server controls that provide UI for the web site. Again, these have limited usefulness to other apps that might use the class library, and no use if the app isn’t a web application.
The most useful part of the engine would be the actual blog providers. These are responsible for building entity classes that represent the content of the blog, and persisting the content within a permanent data store. BlogEngine ships with an XML provider and a SQL Server provider. The providers could be useful to a wide variety of applications, but unfortunately there is still a heavy assumption of a web site context within the providers and the entity classes. So, if you wanted to write a windows application to manage content within your blog, these providers and the entity classes will probably not work out too well for you without re-architecting to eliminate the reliance on web context.
Architecturally, I always have reservations when I see the provider design pattern being applied to an entire tier like this. Providers work great when applied to a specific and narrowly defined “service”, but providers used as whole tiers don’t scale very well, they overcomplicate things, and they can make maintenance or later extension much too difficult and cumbersome. Fortnatly BlogEngine's DAL is fairly small, so it doesn't suffer too much from these problems yet.
Having criticized the code, please let me say that the programmers that wrote this code are VERY good. This is not the work of armatures or idiots. The code is clean, neat, and organized. While I dislike how the code was architected, I have to acknowledge the development team’s skill and professionalism too. The code is very well written.
As for the web site itself, it follows a simplistic approach to skinning. The UI code is a mix of asp.net pages, master pages, user controls, and server controls. Quite a lot of the content displayed on the UI is generated by direct method calls with the output directly injected into the HTML. You’ll see a LOT more <%= GetSomeHtmlOutputAndPutItHere() %> type things within the pages than is typical in most asp.net apps. This simplicity gives a lot of freedom in skinning the application, but it also tends to get a little chaotic. The skins resembles php or classic asp apps a little more than I personally like. You’ll have to use existing skins as a guide to build your own skins, and you wont get as much use from Visual Studio designers either.
On the plus side, the skinning is usually a matter of just editing a master page and two user controls within the theme folder. I’ve implemented two sites on BlogEngine now, and with both I found several things that required editing code outside the theme though. And some of those changes were in code within server controls from the class library assembly too. While this is fine with me, it does mean that the site ends of being hard-coded to the one theme I created. This isn't a problem, but it does indicate that the skinning appraoch could still use some work.
Another issue that I’ve not investigated is performance and scalability, but I suspect that this app would have trouble with large amounts of content. I suspect that the XML provider would suffer performance issues much sooner and more severely than the SQL provider would. But performance will be great for most blogs since they don't tend to get that large.
The verdict:
- If you want a good personal blog, and want to host it on your own server or web hosting account, then BlogEngine is a good choice. It will provides all the functionality you’d need and a few good extras too. It will not be too difficult to create a custom theme for your site as long as you are good with HTML/CSS and are somewhat familiar with asp.net.
- If you want code that you can use in your own application to help you with blog or blog-like functionality, then move along. Also, if you need multiple blogs hosted within one web site or have a high-volume blog, then BlogEngine is probably not for you.
No comments:
Post a Comment