在SharePoint 2013中，引入了一种新的应用程序类型：SharePoint App。在这里，App这个词并不是泛指应用程序，在SharePoint 2013中，它用来描述一种特定的SharePoint应用。那么，到底什么是SharePoint App呢？
历史，以及手机App的兴起
如果你曾经向SharePoint用户讲解过如何使用SharePoint，那么一定知道，要清晰明了的讲清楚SharePoint里面的诸多概念，是一件多么麻烦的事情。一个SharePoint网站里面有列表、有文档库、有图片库…列表还分成联系人、日历、链接、任务…这些还不包括我们开发人员所定制出来的其他不同的功能组件。SharePoint网站中包含了太多的不同类型的“数据容器”和不同类型的功能组件，而用户要搞清楚这些概念和它们的区别，是一件很麻烦的事情。为什么使用SharePoint不能就像我们使用智能手机一样简单呢？
在使用智能手机时，如果用户需要某个功能，他只需要打开App商店，然后搜索到想要的App，安装它，就可以在自己的手机上使用这个App。每一个App都可以非常容易的被安装，每一个App的运行（理论上）都不会影响其他的App。如果用户不再需要某个App了，只需要直接从手机上删除它，而不用担心删除这个App会让自己的手机出问题，或是导致其他App工作不正常。
移动设备软件工程师在创建App时，总是将App做成一个具备独立、完整功能，与其他App不具备（或几乎不具备）依赖性的独立的应用程序。开发完成后，只需要将App发布到对应平台的App商店（Apple App Store、Google Play、Windows Phone Store），就可以非常方便的将App分发到万千用户的设备上。在对App进行了更新之后，也只需要将更新后的App重新发布，用户手里的设备就能自动提示用户，将App更新到最新版本。
总结一下手机（和其他智能设备）上的App，它们几个核心特点包括：
- 高独立性：独立提供一个相对完整的功能
- 高隔离性：App之间的数据相互隔离
- 高稳定性：App不会影响设备（运行平台）本身的稳定性
- 分发便利：App可以非常容易的通过App商店进行分发，用户也可以非常容易的从App商店搜索并安装App
（让我们暂且把手机设备上的这种App运行与分发机制，称之为App Model。）新型的App Model相对于传统的应用程序模型，有着非常显著的优势。无论是从开发的角度，还是从最终用户使用的角度，App Model都是一种更受欢迎的模式。它很大程度上避免了自定义应用程序复杂的部署和维护操作，简化了开发过程、部署过程和使用过程。
手机App Model仍在方兴未艾的发展着，并且在向更复杂的设备蔓延。下图是笔者从自己安装了Windows 8操作系统的笔记本上，打开Windows Store所看到的界面。通过Windows Store，用户可以直接安装Windows Store App到Windows 8操作系统中。
SharePoint网站中的所有功能内容都是App
说了半天手机上的App Model，那么它到底和SharePoint 2013 App有什么关系呢？简单来说，SharePoint 2013接受并应用了类似手机设备上的那一套App Model模型，建立了一种新型的SharePoint App Model。对照一下手机App的几个核心特点，SharePoint App Model同样提供了类似的特性：
- 高独立性：每一个SharePoint App都提供了一个相对完整的功能。
- 高隔离性：安装一个SharePoint App时，它都自动被部署到一个新建的专门的SharePoint网站中（这个网站被称为AppWeb）。
- 高稳定性：SharePoint App不允许在SharePoint服务器上运行服务器端代码（Server Code），所以它对SharePoint系统的影响被减少到最小。
- 分发便利：SharePoint App可以被发布到Office Store上，SharePoint网站用户可以直接从Office Store上，购买一个SharePoint App后（如果它不是免费的），将一个SharePoint App安装到自己的SharePoint网站中。
在之前版本的SharePoint中，用户在一个SharePoint网站中看到的，是一些诸如列表、文档库之类的类型。从SharePoint 2013开始，对于最终用户而言，他在一个网站中看到的任何功能组件和内容，都是一个一个的App。例如，通过“网站内容”链接查看一个网站中的所有内容，对于用户而言，看到的全部都是App。
点击“添加应用程序”按钮，用户就可以向网站中添加新的App。可以添加的App，包括SharePoint 2013内置的App，诸如文档库、任务、图片库等等（没错，现在文档库、任务也都是一个一个的能实现某个功能的App了）。
在页面的左侧，有一个“SharePoint应用商店”链接，点击这个链接就可以直接页面上展现出Office Store中的SharePoint App。网站管理员可以通过这个界面，直接购买并安装一个SharePoint App到自己的网站中。注意看浏览器的地址栏，这时用户并没有离开自己的SharePoint网站，SharePoint网站会自动访问到位于互联网上的Office Store，并将SharePoint App的信息显示出来。
可以看到，一个SharePoint App在使用上，非常类似于一个手机上的App。不需要专门IT人员，网站管理员就可以自己从Office Store上浏览、搜索和安装一个SharePoint App。通过引入全新的SharePoint App Model，SharePoint 2013建立了一个新的应用平台，同时通过Office Store，也建立了一个新的生态圈。
SharePoint App和以前的SharePoint Solution有什么关系？
如果你曾经在SharePoint 2007或2010上开发过SharePoint Solution，那么看到这里，你冒出来的一个念头很可能是：嗯，SharePoint App看上去很好的样子，但是它和我之前创建的SharePoint Solution是什么关系？它们是同一个东西，只是改了一下名字吗？我可以将一个SharePoint Solution Package（.wsp）直接当成一个SharePoint App，发布到Office Store上去吗？
这个问题的简单答案就是：一个SharePoint App不同于一个SharePoint Solution，你也不能把一个wsp解决方案包直接当成一个SharePoint App发布到Office Store上去。
为了更详细的解释这个问题，让我们回过头来看看，开发一个SharePoint Solution是怎样的一个流程：
- 在Visual Studio中创建一个新的SharePoint Solution项目
- 向SharePoint Solution中添加各种不同的SharePoint Item，并将它们组织成一个或多个Feature
- 整个SharePoint Solution被Visual Studio打包成一个Solution Package（wsp文件）
- IT管理员将wsp文件复制到SharePoint服务器上，用PowerShell安装它
- IT管理员用PowerShell或管理中心将Solution部署到SharePoint Web应用程序中
- 网站管理员通过网站集或网站功能管理，根据自己的需要，激活或停用某个通过Solution Package安装的Feature
- 用户使用通过Solution Package（以及其所包含的Feature）所安装的各种组件，例如Web部件、页面、列表…
- 如果Solution Package有更新，IT管理员使用PowerShell在服务器上对Package进行更新
在整个Solution Package的部署和管理过程中，都离不开IT管理人员的参与。IT管理人员通过PowerShell之类的专业工具，在服务器上实现对Package的各种管理。
接下来让我们看看一个Solution Package是如何在SharePoint服务器上运行的：
- Solution Package中包含的大部分自定义组件，都以.NET代码的方式来实现，它们在服务器上的w3wp.exe进程中运行
- 有些代码可能运行在其他进程中，比如计时器作业会运行在owstimer.exe进程中
- 沙盒解决方案中的代码会运行在专门的沙盒进程中
Solution Package中的大部分组件，是以一种“侵入性”很强的方式，在SharePoint服务器上运行的。从本质上来说，SharePoint服务器被作为一个ASP.NET Web运行平台，而Package中的代码，大部分都是以标准ASP.NET方式，以Page、Web Control的形式，运行在服务器的应用程序池中。无论是Application Page还是Site Page，都无非是一个标准的ASP.NET Page，而Web Part更是一种标准的ASP.NET Web Control。这种运行模式，对SharePoint服务器本身是一种相当大的冲击，更是SharePoint系统稳定运行的大敌。随着SharePoint系统在企业中的地位越来越高，企业也原来越不希望SharePoint系统出现任何的问题，而原本的SharePoint Solution模式，是很难达成这个目标的。无论是Solution的开发，还是它的部署和维护，都会不同程度的对SharePoint系统造成影响。少数对SharePoint系统稳定性和安全性非常高的企业，干脆禁止了在SharePoint服务器上运行任何自定义代码，这在某种程度上，体现出了SharePoint Solution模式的困境。
正是为了迎接SharePoint Solution所面临的这些问题，SharePoint App Model应运而生。通过借鉴和吸收手机App Model的特点，SharePoint App Model要解决的，正是上面所说的这些问题。SharePoint App带来的好处包括：
- 一个SharePoint App不会对SharePoint服务器产生严重的冲击（因为SharePoint App不允许在SharePoint服务器上运行服务器端代码）
- SharePoint App之间有高隔离性（每个App都有自己独立的AppWeb）
- SharePoint App的部署不需要IT管理员的参与了（通过Office Store就可以轻松搞定）
所以，SharePoint App并不是将SharePoint Solution仅仅换了一个名字而已。它从架构，到开发方式，到部署分发方式，到运行方式，到所用到的核心开发技术，都和SharePoint Solution有显著的区别。一个SharePoint Solution是不太可能经过简单的修改（比如在xml清单文件里面加上几个属性），就直接被转换成一个SharePoint App的。SharePoint Solution Package更不能直接被发布到Office Store上。
SharePoint App Model对于开发人员意味着？
在前面的段落中看到“SharePoint App不允许在SharePoint服务器上运行服务器端代码”这句话的时候，会不会感到眼前一黑？别着急，而对于开发人员，SharePoint App实际打开了另外一面更大的门。SharePoint App对于开发人员意味着：
（1）开发人员可以使用任何自己想要的服务器端技术来开发App
没错，从此，开发人员不再被限制在ASP.NET上。如果愿意的话，开发人员可以使用ASP.NET MVC、PHP、Java、Node.js…各种不同的服务器端技术，来创建App。
想想我们手机上的App。大部分手机上的App，实际上只是整个应用中最前端的、面对最终用户的部分。在一个手机App的后面，可能隐藏着一个庞大的服务器场系统，为千万个被安装在手机终端上的App提供后端服务。当我们启动手机上的一个App时，这个App会连接到互联网上某个服务器系统上，获取数据、更新数据。无论那个后端的服务器端系统是使用何种技术构建（.NET或Java或其他平台技术），对于手机设备而言，这个App“只是”一个标准的Windows Phone App或Android App或iOS App而已，手机设备不关心App的后端服务器端系统。App开发人员拥有100%的*。实际上，对于一个热门的App，开发团队必然会基于一个统一的后端服务器系统，为不同的设备（Windows Phone、Android、iPhone），用不同的App开发技术，开发不同类型的App。
SharePoint App同样如此。对于大多数SharePoint App而言，SharePoint网站并不关心这个App的后端服务器系统使用了何种技术平台，是使用的ASP.NET MVC还是ROR。对于SharePoint网站，这个App“只是”一个标准的SharePoint App而已。
（2）SharePoint App可以被host到不同地方
SharePoint App可以使用任何后端服务器端技术，它也可以被host到不同的地方。如果一个SharePoint App中的所有功能都通过SharePoint本身来实现和完成，那么可能它可以直接被host在SharePoint上（这种App被称为SharePoint-hosted App）。
对于一个更复杂的SharePoint App，它很可能要通过专门的后端服务器应用来实现。除了SharePoint-hosted App之外，将App host到其他环境中的方式，被称为Cloud-hosted。Cloud-hosted又分为两种情况：
- Provider-hosted：找一个专门的环境来host，比如某台专门Windows Server上的IIS，或Linux Server上的Apache，或Windows Azure/Amazon的云服务。这种由App开发商来提供的某个环境，都被统一称为Provider-hosted。
- Auto-hosted：App自动使用Windows Azure来作为host，当SharePoint安装App时，能自动将App中包含的Web网站给发布到Windows Azure上。这种host模式只适用于Office 365上的SharePoint网站，并且你同样需要购买Windows Azure订阅。
当然，一个SharePoint App也完全可以某些部分host到SharePoint里面（SharePoint-hosted），另外部分则host到另外某个环境中（Cloud-hosted），这种混搭的方式，被称为Hybrid-hosted。
（3）SharePoint App开发人员不再需要对SharePoint技术体系有太深的了解
还记得在为SharePoint 2007/2010开发Solution的岁月里，无数的开发人员为了深入了解SharePoint平台本身，耗费了无数的青春和岁月。在开发SharePoint Solution时，对SharePoint系统的深入了解是不可或缺的。一个熟练的ASP.NET开发工程师要成为SharePoint工程师，还需要经过大量的学习和实践，才能掌握SharePoint中无数的“秘密”。但在开发SharePoint App时，开发人员所需要对SharePoint的了解程度，被大大降低了。这对于开发团队，无疑是一件美好的事情。
（4）JavaScript将是SharePoint App的骨干支撑技术
JavaScript早已经成为了现如今Web开发中最重要、最核心的技术之一，随着我们从SharePoint服务器端代码中解脱出来，JavaScript的作用被凸显了出来。在SharePoint App中与SharePoint系统的交互，几乎都是通过JavaScript来完成。微软极大地丰富了SharePoint的JavaScript Client Object Model（JSOM），让我们可以通过JavaScript做更多的事情。另外，SharePoint 2013的REST接口也可以让我们从JavaScript中更方便的获取SharePoint网站中的数据。
那么，到底要如何开发一个SharePoint App呢？用一句话回答：仍然是使用Visual Studio。下图是Visual Studio 2012中的SharePoint App项目模版。
本系列文章的目标，就是想你讲述SharePoint App的开发，所以在这里我们就先暂时打住了，具体的开发步骤、开发方法，在后面的系列文章中将相继讲述。
SharePoint App是用来取代SharePoint Solution的吗？
我知道你在想什么。上面说了这么多SharePoint App的好处，那是不是意味着，SharePoint Solution开发模式就要死了，以后所有人都将使用新的SharePoint App Model了？
如果在开发之前的评估阶段，你发现你要实现的需求，既可以通过SharePoint Solution实现，也可以通过SharePoint App实现，那么我会建议你使用SharePoint App Model来开发。但是（！），在很多时候，事情都不会这么简单。SharePoint App Model由于其自身的特点，它有很多事情是做不了的，或者说是不适合做的。比如，SharePoint App中的Feature的范围，总是Web（网站）级别，而不能是Site、Web Application和Farm级别。从笔者个人的观点，如果你是需要基于SharePoint系统，对它进行比较深层次的扩展，那么很可能SharePoint App就不是你的菜了。（这就好像如果你要对Android原生系统做一个深层次的扩展和定制，那么一个标准的Android App是不太可能满足你的要求的，相反，你可能需要做一个定制ROM，就像MIUI ROM做的那样。）
所以，SharePoint App并不是一项用来完全取代SharePoint Solution的技术体系，在某些方面，它无法取代SharePoint Solution的作用。开发团队需要根据自己的需求，慎重的做出选择。
企业能不能自己建立一个内部的“SharePoint App Store”呢？
完全可以。如果SharePoint App是为特定的企业系统所创建的，那么是没有必要将App发布到Office Store上的。另外，企业内部网络可能根本不允许连接到互联网，那就根本没法通过Office Store向SharePoint网站安装App。
在企业内部部署的SharePoint系统中，可以通过创建App Catalog（应用程序目录），来进行App的分发。
