I've put a lot of thought into how I might go about formulating an answer to this question. If anyone knows me personally, they'll know I'm pretty passionate about things that I care about, and Dynamic Sites Manager was pretty much the love child between immense frustration about how other Site Managers were going about doing it and the fact that I had a week off of time between Christmas (2014) and New Years (2015). So it's with that disclaimer that I tried to provide as much objectivity in this answer as possible.
Birth of Dynamic Sites - Doing Multi-Site the Sitecore Way!
I wanted to figure out how Sitecore intended to do multi-site. The goal being, I didn't want to override a SINGLE Sitecore class.
So the requirements ended up being:
- No Class Overrides
- Must be able to add sites in the Sitecore editor.
- Must be able to add sites without a worker process recycle
- Prevent caging people into using a specific templates (as much as possible).
- Must be fast
- Must not adjust, muck, or any way alter
- It must solve the problem.
And that's exactly what I did. Dynamic Sites adds additional Site Providers to the mix. Executes and respects the
ConfigSiteProvider out of the box, and implements it's own
DynamicSiteProvider class along side of it. The custom provider only cares about it's sites and nothing else. I also added a switcher provider that allowed me to combine all of the providers in order to feed the
SiteCollection. I also included some custom Sitecore caching to cache the Sites so that retrieving site information was as fast as possible.
The end result being that
Context.Site is updated, naturally, without being forced, Sitecore is aware of all sites (no sites masked), and all sites even had their own Sitecore site caching for things like xsl, html, and data caching.
I decided to launch it as a Marketplace Module, provide the Shared Source license for use, and post it on Github.
Was/Is it perfect?
Oh god no. It was a rush job, at least the early iterations of it. As time past, I made small tweaks here and there as bug reports from users using it out in the wild started providing me with information. I tried to respond to all of them posting small updates as fixes were implemented.
Current State of Dynamic Sites
When Sitecore 8.2 was released, I immediately spent the night updating Dynamic Sites to support 8.2 and went through all of my test cases to ensure it was still functional. More information about this can be found on my blog, Sitecore Hacker.
Future State of Dynamic Sites
As much as it needs to be, I will continue to provide updates for the module. I am also working on Version 2.0 which is being completely rewritten to support Helix guidelines. In addition, I am planning on seeing how Dynamic Sites Manager needs to be adjusted for the Solution Experience Accelerator and taking into account Habitat's multi-site solution. As needed, I will make adjustments.
How does it differ from Niket's Multiple Site Manager
Niket took an entirely different approach, but ultimately he tied into the system by overriding the
ConfigSiteProvider with his own class as well as injecting logic into the
httpRequestBegin pipeline. He does manage to register the site with
SiteContextFactory but does it in a way that requires him to lock down the factory from other threads while he builds the Site context for each site. He does this during the
httpBeginRequest pipeline which means during the first request visit after a restart, Sitecore has to sit there and rebuild the site collection.
He also goes through and hard codes some of the default Sitecore sites in order to appropriately order them since
publisher are all special sites that have to come AFTER custom site definitions.
And last, but not least, he updates new sites by
touching the web.config which performs a worker process recycle to restart the Sitecore services. By doing that, the first request of
httpBeginRequest is able to process and create his site definition again.