I enjoy coming up with ideas on how to solve problems. If I can do so in a way that is maintainable, scalable, and beautiful, then all the better. If I can do so in a way that is extremely simple, I get a geek orgasm.
About five years ago, I was working on a project that needed to be future proof. In other words, we had to take into account what didn’t exist yet or was even dreamed possible at that point. We had to support SharePoint 2013 at a time when nobody even knew about SharePoint 2010.
To solve this problem, I created a framework for building solutions in SharePoint that are maintainable, scalable, and extensible. The framework handles deployment of functionality for new sites, but equally important, tracks and maintains existing sites as well, so you can be sure to always have the latest version of your functionality on any site.
The framework allows you to follow software development ideas such as Agile, and has no side effects. Like other great frameworks, it is based on convention and loosely coupled components that are easily interchangeable.
This must sound awfully complex, right? Requiring tons of third tier code and .NET stuff, probably.
The opposite is the case. In fact, you don’t need to write a single line of code in Visual Studio (although it does make things easier and a lot more powerful). So, you can use this framework knowing little more than how to build a .WSP, and frankly, if you don’t, you probably should be careful about doing any kind of development in SharePoint, third tier or not.
Another aspect of good development is that the result shouldn’t be dependent on the tool used to build the result. A good example is .NET; it doesn’t matter what tools or even language you used to build a .NET component or program, it will work the same regardless, and you can mix and match tools and languages in a project as much as you want.
You may know that I am a huge fan of WSPBuilder as opposed to the brain dead Visual Studio Tools for SharePoint Development that ship with VS2010 and onward.
Using my framework and its recommended practices, developers on the same project can utilize whatever tools they want to build their solution. I can use WSPBuilder and run laps around everyone else, while retards and continue to use their point-and-click development if they choose to remain idiots. We can combine our components into one beautiful solution which doesn’t care what tools, language, or approach we use individually.
Of course, unless you’ve been paying attention, you haven’t really heard about much less used this framework already, so it must be too late to implement it now, right?
Again, no. My framework can be installed into any farm at any stage of development and can be utilized or ignored at your whim. If or when you decide to start using it, the framework can work with any site, regardless of how that site is created, from which template, and so on. The framework will simply handle the deployment of functionality that supports the framework conventions.
So, there must be a lot of installation and maintenance, then? Supporting all of this in a single framework must take a lot of complex and opaque code.
No, not this either. The entire framework consists of 42 lines of code. They are the same 42 lines of code I’ve used since 2009. In some cases, I’ve extended the code slightly to create branching of upgrades (for example to support certain functionality for Team Sites and certain functionality in MySites, but using the same framework) but beyond that, the code is extremely simple.
Oh, and it has no side effects either. In other words, it doesn’t require you to make changes to your farm, nor does it make changes to the farm. In fact, you can easily install and uninstall the framework at your whim. Any solution you have already made will work just as well without the framework, except, of course, you won’t get the functionality that the framework offers. Instead, you’ll just have to deploy the functionality manually like you’d do in a non-framework solution.
I’ve used this framework on anything from small mom and pop shop solutions to some of the largest SharePoint solutions in the world, covering dozens of servers, tens of thousands of site collections, spanning several continents and running for years without interruption.
Right now, I’m in the process of re-architecting a multi-year, multi-farm, multi-continent SharePoint solution to use this framework. After the decision was made, I had the framework ready for installation within 7 minutes, and that included the time it took to build everything from an empty Visual Studio solution.
I wouldn’t call it supernatural or anything like that.
In fact, I would call it Magick.
As time permits, I’ll explain how it all works here on this blog. I’ll give you the source code (or put it on Codeplex; I don’t know yet), and I’ll share my recommended practices after using it for close to five years. I’ll show you some cool ways you can utilize and extend the framework without breaking compatibility or conventions.
I’m not sure how quickly that will happen, though because I’m fairly busy on other things at the moment.
However, if you’d like to get everything right now, I’ve actually written a USP Journal about this framework. It’s called Professional SharePoint Development, and it’s available from http://professionalsharepointdevelopment.com/. It contains the source code and sample solutions using the framework too.
Note: Feel free to ignore the first part of the journal issue and look at the second part only. The first part deals with deconstructing a site template and isn’t relevant to how the framework functions.