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:
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) { Post be_post; Entities.Post post; using (IRepository<Entities.Post> r_post = RepositoryFactory.Build<Entities.Post>()) { post = r_post.GetById(id);
if( post == null ) return null; } 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)); c.RegisterType<SitkaProxyFactory, SitkaProxyFactory>(); c.RegisterType( typeof(EntityMapper<T>), typeof( GenericMapper<T> ) ); c.RegisterType( typeof(IRepository<T>), typeof( Repository<T> ) ); IRepository<T> r = c.Resolve<IRepository<T>>(); r.TenantId = Constants.BlogEngineContainer; 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:
Things that I missed or would have liked to be different:
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.
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.