SharePoint is a massive platform that contains many features. When looking at building a solution, the first question is really: What do I use? Once you ask the question, you start searching the Internet for the answer. As you trawl through the search results, you will see many different ways of doing the same thing--using all kinds of configurations, out-of-the-box components, client-side hacks and even server-side code. Yet these posts don’t often answer the questions: Which one is the best approach, and which one will actually work in our environment?

For me, the real questions to ask are the following:

  • Am I building it for SharePoint On-Premises?
  • Am I building it for SharePoint Online?
  • Is it an internal-only or external-only solution?
  • Am I consuming content from other systems?
  • Do I need extra security or custom security to make the solution work?
  • What core out-of-the-box building blocks do I need to use?

These and more questions like this are common when working out how to build a solution. Historically, solutions have been built using either completely out-of-the-box features, client-side code to retrieve and style either internal or line-of-business data, custom-managed code or third-party components. Very rarely is a solution just one or the other, so this means we have to utilize elements of each approach.

SharePoint supports different options for building solutions. If we are using out-of-the-box components, then our core building blocks will be:

  • Content Types
  • Libraries and Lists
  • Page Layouts
  • Master Pages
  • Web Parts

If we are going to build a fully deployable solution that can scale both On-Premises and Online, then packaged code is the option. SharePoint supports the following code options:

  • Full Trust Code packaged into WSP files
  • Client Object Model Code packaged into Sandboxed Solutions
  • Client-Side code, JavaScript and jQuery deployed manually or wrapped into Sandbox or Full Trust WSP files
  • Add-In (formally App) Development

If the solution is being built for Office 365 only, then the code options become a little more limited due to restrictions within the platform. The options are then narrowed down to the following:

  • Client Object Model Code packaged into Sandboxed Solutions
  • Client Side code, JavaScript and jQuery deployed manually or wrapped into Sandbox
  • Add-In (formally App) Development

Understanding the limitations and options available will allow us to build a better solution. There are other components available to us for other features that could be required. If we are building a solution that needs to aggregate content, create reports or just combine content into views, then we would look at using search along with some of the business intelligence components such as Power BI if we are on Office 365.

If the base requirement for our solution is to provide a mechanism to provision sites easily for all users without using the out-of-the-box functionality, then we have a couple of different approaches.

To help us determine what to use, the following is a business requirement statement: “Users must be able to complete a form that will automatically provision a sub site. This form must create a master record in a list for the provisioning of the site, which will contain all the values needed to create it. The form must require the end user to complete the various properties along with assigning taxonomy values. Once the entry is added, an approval process needs to be completed, after which the site will be created.”

Now that we have our base requirement, we can break the features into categories.

Out of the Box

A SharePoint List will be used for the storing of the site creation entry. A custom content type will be defined that contains all the site columns that are needed including taxonomy values for tagging for the site. A newly created workflow will be associated to the list, so when an item is added an alert will be sent for approval. Upon approval the process will complete and create the site based on the properties entered in the initial form.


The form itself will be custom-created using standard code. Either approach could be used--client- or server-side--allowing for list entries to be added, as well as allowing for a rich functional form.

As you can see, even something as simple as this utilizes various development approaches for creating the desired solution. Of course, there are many more approaches that could be used for this example requirement, and that is the point. There are always multiple options to creating a solution within SharePoint, and not all of them need to start directly with "custom code."

Of course if you have to write custom code for SharePoint On-Premises or SharePoint Online now, you would look at building Add-ins (formerly known as Apps).

These solutions are now decoupled from the rest of SharePoint, allowing for better performance, scalability, security and management. The core logic is to remove the inherent dependency of full trust code, which means that SharePoint services and components will not be affected by bad code or just plain old memory leaks.

More details on the Add-in Model and SharePoint Development can be found on MSDN.

Register for IT/Dev Connections 2015!

Hopefully this gives you a basic idea of what options are available now for SharePoint Development, as well as what types of questions to ask that will help you determine the final approach and solution. At this year’s IT/Dev Connections conference at the ARIA Resort Hotel in Las Vegas, you can attend a session by Bob German called “Building Modern Web Applications Using SharePoint Micro-services” that will lead you on the journey of building solutions for and with SharePoint.

IT/Dev Connections promises to be a valuable show for anyone who wants actionable insight and content, as well as the opportunity to collaborate with IT peers. Click here for more details on IT/Dev Connections and to register. Use the code ITDCCLEARY15 for $100 off.