Another SSDS sample: BlogEngine.NET on SSDS

  • Article

As a by-product of a project I'm working on, I've got a working version of BlogEngine.NET on SSDS. You can download the provider and other related components from LitwareHR's web site releases section here.

In the package you will find:

  1. The SSDS based BlogProvider
  2. An SSDS based Membership & Role Providers for the web site
  3. Unit tests for all (with about 93% coverage for the provider)
  4. A simple tool for pre-loading the SSDS container with information that BlogEngine need to start

The underlying data access is inspired on LitwareHR's, although I've heavily refactored it. The key ideas remain the same: there's a Repository<T> type, it uses SOAP to access SSDS, etc. but the code is simpler, responsibilities are better balanced and distributed, and I eliminated superfluous code here and there.

The new SSDS BlogProvider also uses patterns & practices Unity application block to wire up dependencies, so you write things like this:

 public override Post SelectPost(Guid id)<br>{    Post be_post;<br>    Entities.Post post;    using (IRepository<Entities.Post> r_post = RepositoryFactory.Build<Entities.Post>())<br>    {<br>       post = r_post.GetById(id); 



        if( post == null )          return null;<br>    }<br>    be_post = SSDSPostToBEPost(post);    return post; 




}

RepositoryFactory.Build<T>() will use Unity's Resolve() method to find the appropriate Repository implementation and all its dependencies configured. Build<T>() body looks approximately like this:

 c.RegisterType(typeof(ITenantManager), typeof(DefaultTenantManager));<br>c.RegisterType<SitkaProxyFactory, SitkaProxyFactory>();<br>c.RegisterType( typeof(EntityMapper<T>), typeof( GenericMapper<T> ) );<br>c.RegisterType( typeof(IRepository<T>), typeof( Repository<T> ) );<br>IRepository<T> r = c.Resolve<IRepository<T>>();<br>r.TenantId = Constants.BlogEngineContainer;<br>return r;

I'm still learning about Unity so there might be better ways of implementing what I did, but it works.

 

Things I've liked about BlogEngine.NET:

  • The provider model. I think it was great design decision that allowed me to write this fairly quickly. I didn't want to look to much into other pieces of BlogEngine.NET, and this provided a clear separation. 
  • The code structure is quite neat. Navigating it was painless and I used the same structure implemented in the XmlBlogProvider.
  • It's a nice app with a lot of functionality and a fun project to work with!

Things that I missed or would have liked to be different:

  • The one thing I missed the most is pre-built unit tests for the provider. 
  • There are some assumptions on the engine and core components about where it runs (particularly ASP.NET) that introduced some issues.
  • I only changed 1 line of code (which was superfluous anyway), and that is this in the Category class in BlogEngine.Core:
 internal static string _Folder = System.Web.HttpContext.Current.Server.MapPath(BlogSettings.Instance.StorageLocation);

This prevented me from unit testing my provider in complete isolation. It turns out that the variable wasn't needed anyway, so I commented it out.

  • There are other features in the app that are not abstracted in the provider (or in another replaceable component). For example, file attachments are handled in the Add_Entry.aspx web page. I didn't want to use the file system at all, but I also didn't want to change the code, so I left it as is. There are other parts of the app that have direct dependencies like this.
  • I wasn't sure about the app exception handling architecture, so I opted to do what the other providers seem to be doing: just throw and hope the upper layers handle it :-).

 

BlogEngine.NET expects some initial data: a user, an admin role and some initial settings. The unit tests will make sure these exist prior to running, and I also created a "Provisioning" console application that populates the container with the needed information. You need to configure all appropriate configuration files with your SSDS credentials.

Finally, because I'm using LitwareHR's data access, you can use the offline proxy to test the system independently from SSDS. So, until you get the SSDS beta account, you can start playing with it.

Feedback is welcome, as usual.