What is the primary difference between the MultipleSitesManager (https://github.com/JimmieOverby/MultipleSitesManager) vs. the DynamicSites (https://github.com/Vapok/Sitecore.SharedSource.DynamicSites) modules?
Looking for reasons why one may be better than the other for a project with dozens of sites. Thanks.
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.
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:
httpRequestBegin pipeline.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.
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.
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.
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.
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 scheduler, system, and 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.
