- Posted by Jakob Andersen on April 11, 2008
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.