A Perspective on SharePoint 2013's App Model - Part 2

  • [アーティクル]

In part 1 of this series, I discussed why the way developers extend SharePoint needed to change. In this article I will detail types of SharePoint applications, how they fit into the app model, and the tools you can use to build applications.

What is a SharePoint App?

The words "SharePoint application" could probably mean a lot of different things to different people. Therefore, I want to do some level-setting before I dive specifically into the new App model. SharePoint provides a lot of functionality out of the box (search, workflow, lists, libraries, forms, content and document management, etc). The idea of building an application is really applying this functionality to a specific business need. I have seen some very effective "apps" that are nothing but out-of-the-box SharePoint functionality. So I thought I would talk about categories of applications first and then dive into the app model which usually enters the conversation when out-of-the-box functionality only gets you part of the way there. In my experience, you can categorize applying SharePoint to business processes along two different axis. These are the complexity of the desired user interface along with the complexity of the data model or business logic.

In the bottom-left quadrant, you have those applications that can be completely delivered by configuring out-of-the box functionality. Assuming the data model and business logic requirements remain the same, you can gain greater control of the user interface by introducing some additional tools. These could be forms (either web forms or those created with InfoPath), HTML 5 JavaScript customizations, or even a browser plug-in such as Silverlight.  The nature of the custom user interface requirements as well the skills of the person doing the customization will drive you to one of these choices. Are you simply trying to add some advanced validation and formatting to data entry of your list? In this case, InfoPath is the quickest way to a solution. As the data model becomes more complex or the business logic needs increase, the complexity of the solution does as well. If you can keep the data model relatively out-of-the-box and need just a place for some custom logic, the usually introducing SharePoint workflows will meet your need. When you need to go beyond a workflow and require to code a business layer or if you need to introduce your own relational database - that is the quadrant of custom apps. When I speak of the SharePoint app model, I am mostly focusing on building solutions with requirements similar to those.

Side Note: Why would you ever need your own relational database? Let's be honest here. The SharePoint content databases are things of marvel. Almost whatever you want it to store a list of any type or tons of content it is really good at it. However, a yellow-flag for any solution is where a developer is using many SharePoint lists with lots of lookups and relationships. Or the developer has a list where they are expecting tons of items. Though SharePoint can store the content in both of these scenarios, should it? The main issues I have seen with applications is that SharePoint's content databases are a block-box. They are hands-off from a supportability point of view. So if you expect to write many reports against an extremely large list, odds are you will find yourself battling performance problems since you can't go into the database and add your own custom indexes. Plus it is important to realize that these lists don't give you much support in terms of transaction boundaries. If you app needs a sort of tracking database - odds are that it is better to host that outside of the content database.

Types of Apps in SharePoint 2013's App Model

In my earlier post, I introduced the major guiding principal behind the new development model in SharePoint 2013. The new model dictates that no server side code be deployed to the SharePoint servers. The only things that SharePoint hosts for the applications are the things it already knows how to do: Lists, Libraries, Workflows, Content (which can include HTML pages and javascript), etc. If to build your application, you need a custom database that you are going to code against, or web services that you need to supplement, or user interface elements that are easier to build in ASP.NET, these things must be hosted elsewhere. It should be noted that not all custom apps will have server side components. Therefore, we use several terms to describe the type of SharePoint app:

  • SharePoint Hosted: A "SharePoint hosted" application is a SharePoint app that contains no server side components. It can deploy everything it needs (libraries, workflows, content, etc) all within the SharePoint environment.
  • Provider Hosted: A "Provider hosted" application is a SharePoint app that has server side components. For these components (usually contained within an ASP.NET application), you must provide a separate environment to host them. If could be a separate, non-SharePoint IIS server. Or it could be a virtual machine running in Azure's Infrastructure as a Service. As I stated in the earlier article, the server side components can really be developed in any technology as long as you can abide by the OAUTH requirements and make REST calls. But since Microsoft has done so much to make these remote components easy to build in ASP.NET, we will assume that going forward.
  • Auto-Hosted: An "Auto-hosted" application is unique to Office 365 and the SharePoint Online service that runs there. If you are deploying on-premises you can cross this one of your list. However, if you are running in Office 365, it is one of the more ideal solutions. An auto-hosted application has server side components, but when you deploy the application to SharePoint, the service automatically spins up the server-side elements in an embedded Azure layer. It isn't Azure like you would manage in IaaS. It is more like the traditional Platform as a Service model where your app is deployed for you in a hosting environment you don't even log into. The biggest benefit of this model is that most of the registration and OAUTH plumbing is completely handed for you.

A little bit more vocabulary.... When you add a SharePoint app to a SharePoint site, it is important to understand where things are going. First, we refer to the SharePoint site you added the app to as the "host web". If the application has things it would like SharePoint to host (such as lists, libraries, content, etc), these components are put in a sub-site of the host web called the "app web". Usually this app web is accessed through a different top-level DNS entry then the SharePoint site to protect against cross-site scripting attacks. Having everything in the app web makes an uninstall very easy. When you remove the application, it removes the app web. Keep this in mind if you expect your data to be persisted despite the removal of your application from the site. You may need to place that content somewhere else like the host web. Lastly, if your application has server side elements, these are hosted outside the SharePoint infrastructure. We refer to that as the remote web.

What Kind of Tools Make SharePoint 2013 Style Apps?

I am going to go out on a limb here and not just make the statement that you need Visual Studio 2012. Almost everything on MSDN jumps immediately to this point. However, there are lot of tools that can get you into the SharePoint app world most with less development chops then Visual Studio would require. In fact, some of them are sort of built into SharePoint 2013 automatically. Here is a list:

  • Access 2013: Yes Microsoft Access. It turns out that a wonderful feature of Microsoft Access is that you can create "web databases". If you are familiar with Access Services in SharePoint 2010, read carefully - a lot has changed. If you design an application with Access 2013 and you choose to start with a custom web database, the application will publish as a SharePoint app. The form interfaces become HTML 5 forms and the data gets housed in a custom SQL database outside of SharePoint's content databases. If you are running in Office 365, this means SQL Azure. On-premises you can designate on what SQL instance these databases should be housed.
  • Napa: The Napa tool is a web based development environment for application that are SharePoint hosted and running in Office 365.
  • Visual Studio Lightswitch: This tool was just recently released with Visual Studio 2012 Update 2. Lightswitch has always emphasized code generation where you customize screen templates and either build your own data model or connect to existing ones. This latest release has an option to deploy as a SharePoint application. The user interface is HTML 5 which is hosted in a remote web or auto-hosted. And the custom data model is housed by SQL Azure or SQL Server on-premises. Lightswitch even supports you referencing SharePoint lists in your data model.
  • Visual Studio 2012: The developers tool.

In the next posts, I plan to go over some examples of applications and a bit more detail on OAUTH. Be on the look out.

Comments

  • Anonymous
    April 24, 2013
    A nice article Ed....and great to know about the tools, especially, Access 2013 publishing an app as a SharePoint app !