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.
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.
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.
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.
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:
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.