一、SharePoint App的由来

    SharePoint App的概念来自最新版本SharePoint 2013。之所以出现App新的开发模式，这要追溯SharePoint历史版本的开发弊端。我使用SharePoint开发企业应用已有6个年头了，回顾MOSS2007的Farm Solution，真是艰辛非常。一不小心就会让SharePoint服务器崩溃。直到SharePoint 2010版本出现Sandbox Solution（沙盒解决方案）后，SharePoint开发变得容易和安全多了。因为Sandbox Solution只能访问自己的资源，并运行在一个独立的进程中，这就保障了不会轻易的影响整个SharePoint服务器场的环境。SharePoint 2013真是一个了不起的版本，它改进了我在历史版本中所遇到的大部分蹩脚的开发，变得更加的灵活、容易、强大。

    随着时代的发展，企业对SharePoint的应用需求发生了重大改变。已经不单单为了服务器端的功能实现这么简单。Web开发中更注重终端用户的体验，跨设备访问、可移植性、扩展性、云端部署、应用的选择和可租用性等。开发者更看重SharePoint成为一个强大的开放性平台，通过组合SharePoint的各种功能来实现复杂应用和客户需求。应用将成为存储、访问、界面的组合。

    为了更好的扩展和安全性，微软在SharePoint上增加几个新的API模型。这些API能够让开发者更轻松和随意的与SharePoint进行沟通。在App开发中，我们会看到微软放弃了服务器端开发模型的使用，改用REST API或SCOM（客户端对象模型），这变得更加的安全。同时，我们可以脱离SharePoint宿主环境，在客户端环境下开始你的编程之旅，这让我这样的SharePoint工程师变得欣喜万分。我们通过客户端模型访问到Sandbox访问不到的全局资源，Apps通过OAuth协议取得对SharePoint资源的访问权限，这让开发变得更加的灵活，安全的可控性也大大提高。

二、SharePoint Apps的发展

    云时代而言，Apps的开发模式的出现，无疑对开发者来说是一个莫大的欢欣鼓舞，我们可以把Apps部署到Azure的公共应用市场。同时，用户可以到Apps市场下载和购买应用。当然这一切也可以在企业内部建立一个私有的Apps市场，这真正做到了用户按需索取功能的实现。

    无疑，今后的SharePoint应用解决方案将以Apps为主流的开发模式。当然Apps毕竟是一个刚出世的技术，微软还有大量的改进需要做，我们共同期待它的下一个版本的到来吧。

    Apps因为是一个新的产物。所以，很多开发者对它的了解不够全面，这阻碍了他们拥抱这个新技术。我摘写这个系列文章，就是为了让大家都能快速的了解它，并轻松开始使用它。因为我工作的时间不够充足，编写这个系列需要花些时间。希望大家能够谅解。

三、Apps的杂谈

    这里所讲的App与Android开发中的App有着或多或少的一致性。比如App直接的独立性、隔离线、稳定性（不影响系统平台）、便利的分发和订阅。说白了SharePoint的App与移动应用有着异曲同工之妙。

    在Win8操作系统中，我们能看到很多App的影子。打开你的Windows Store，从中可以查找、下载、安装App应用。在SharePoint 2013的网站集中，更是无处不在的App存在着。几乎所有的功能都是用App组建的。App之间都有自己独立的功能，相互之间被分别部署到独立的SharePoint网站（此网站称为App Web），App是不允许运行服务器端代码的，App可以分发到Office Store上，用户可以从中订阅使用。

    自SharePoint2013开始，网站集中存在的列表库之类的功能都将以App的模型方式搭建起来。我们在“网站内容”页面中看到的众多功能都是一个个的App。

    在网站中的左侧菜单中，还会包含一个“SharePoint应用商店”的超链接上下文菜单，进入这个页面，管理员可以在这里购买和下载App并安装到自己的网站中

四、App与以往的SharePoint Solution Package（WSP）之间的区别

    首先，它们肯定是不一样的，它们之间是不可替代的。你不能把一个SharePoint Solution当成一个App去部署了。这从VisualStudio的项目创建类型上一眼就看得出。这里多说一句，我建议大家使用最新版本的VS开发工具去创建APP和Soluton项目，因为使用新的IDE会让工程师开发他们变得更加的方便和容易。

    关于如何开发、部署WSP，可以从我写的SharePoint开发部署WSP解决方案包这篇博客中找到一些知识点。这里我再多说几句WSP的开发过程：

    • 利用VS去创建一个SharePoint Solution

    • 向Solution中添加不同类型的SharePoint Item

    • 将这些Item组织到Feature中打包

    • 利用VS工具将方案打包成WSP文件

    • SharePoint管理员将WSP文件放置到服务器上，并利用PowerShell命令将它安装到SharePoint Farm

    • 然后把场中的解决方案部署到Web Application

    • 最后，我们去网站集中激活或停用解决方案中的那些Feature。当然一个解决方案中可能会包含多个Feature，你根据自己需要分别控制他们是没有问题的。

    整个过程都需要SharePoint管理员去参与其中。

    SharePoint Solution在服务器上的运行过程：

    • 在解决方案包中会包含很多自定义的组件，有一些是通过.NET代码来实现的，他们在SharePoint FE服务器的w3wp.exe进程中运行。

    • 有些特殊的代码可能在其他的进程中执行，例如事件接收器、计时器作业就是在OWSTimer.exe进程中执行。

    • Sandbox解决方案会在自己特有的沙盒进程中执行。

    SharePoint App特点：

    • App并不依赖ASP.NET技术，任何服务器端技术都能应用到App的开发中。例如MVC，Java，NodeJS

    • App可以Host到SharePoint上，也可以Host到Cloud。Cloud-Hosted分为两种情况：

      • Provider-hosted：在一个专门的Web服务器上，例如IIS，Apache或Azure，这个环境一般是由App开发商来提供的。

      • Auto-hosted：App自动使用Windows Azure来host，这个模式只适用于Office365（简称O365）的SharePoint网站上，当然你必须去购买Azure订阅。开发这类的App，你必须去申请一个开发者帐号，默认可以免费使用一年，之后付费使用。

    • 当然你还可以将App的一部分host到SharePoint-hosted，一部分host到Cloud-hosted，这称之为混搭模式（Hybrid-hosted）。

    • 工程师对SharePoint模型的理解变得容易上手，主要技术将落在前端技术层面。通过JavaScript Client Object Model（JSOM），我们可以实现很多复杂的工作并完成于SharePoint的交互。

    • App支持远程客户端开发，并远程部署。

    • 建立企业独有的SharePoint App Store。没有问题，我们通过建立App Catalog（应用程序目录）来管理和分发App。如何搭建这个环境，我会在后续的文章中提到。

SharePoint的局限性：

  • App只能部署到Web这个层面，不能操控Site，Application，Farm

  • 在SharePoint API模型中，服务器端编程模型中涉及的部分，对App而言是无能为力的。从在SharePoint 2013中选择正确的API文章中，我们就能清晰看到。