在聊SharePoint开发之前,有必要说下什么是SharePoint.
在我工作的过程中,经常遇到客户对SharePoint不太了解的情况。有客户说,SharePoint太烂了,DropBox能做到的什么什么功能,SharePoint竟然做不到,很明显这种客户把SharePoint当成了一个云盘。那么什么是SharePoint呢?
根据Microsoft的说法,SharePoint是一个企业级的协作平台。这个说起来有点抽象啊 :) 那我们先看看SharePoint的发展历史吧。其实最开始的时候,SharePoint不是这么个大家伙。
1. SharePoint的发展历史。
1)其实SharePoint在开始之初,其只是一个很小的产品,最开始是Sharepoint Team Service 1.0 ,其作为Frontpage的一部分。
2) 后来发布SharePoint Team Service2.0. 其与第一个版本的最大区别在于:所有文档的存储都放到了数据库中,而不是普通的文件文档存储在目录结构中。而且支持版本控制了。
3) 再后来发布了SharePoint Team Service 3.0. 我们通常称之为MOSS 2007 ( Microsoft Office SharePoint Portal Server), 其开始支持WFF及.NET 3.0了。该版本和Office 2007一起发布, 该版本的发布标志着微软的下一代企业级协作软件平台的诞生。
4) 随后Microsoft 发布了SharePoint 2010。
5) 现在最新版本是SharePoint 2013. Office365上部署的SharePoint正是该版本。
2. 什么是SharePoint?
不同的人眼里, 会对SharePoint有不同的认识。在某些人眼里,SharePoint是一个文档存储中心。还有些人认为,SharePoint是信息共享的地方。或者认为SharePoint是快速创建网站的工具;还有些人觉得SharePoint是一个构建企业级应用的平台。
其实,这些观点都没有错。不同人的眼里,不同的用法,就可以把SharePoint当成不同的东西。 对于那些把SharePoint当作文档存储的用户来说,所以我们能理解他会把SharePoint 和DropBox做比较,那是因为他没有完全理解SharePoint,只是单纯地把SharePoint理解为一个文档存储中心了。
实际上, SharePoint 确实可以实现文档存储。而且SharePoint在早期,确实是用做文档存储的。 但是现在的SharePoint, 远远不止是一个文档存储中心了。
那么,回到初始的问题:到底什么是SharePoint呢? SharePoint是一个企业级的企业协作平台。通过这个平台,你可以共享文档,你可以和同事协作完成某件任务,你可以自动触发某个工作流等,你甚至可以和其他的产品和平台进行交互和通讯。
上面说到的大多数功能,其实通过SharePoint的管理员的管理和设计,基本都可以达到了。但是,如果要实现一些更高级的与实际业务相符的定制功能,就需要进行SharePoint的二次开发了。因此,接下俩,我们会从SharePoint开发者的角度,来看待SharePoint的结构了。
3. 开发者眼中的SharePoint结构。
如果从开发者角度来看待SharePoint的话, SharePoint的基本结构如下图所示:
也就是说, SharePoint中的每一个文档,每一个Item,每一个Site等对象,都可以通过其相应的.NET 对象访问到。
那么问题来了,作为开发者来讲,可以通过哪些方式和SharePoint来交互呢?
4. 开发者怎么和SharePoint进行交互?
1) 自SharePoint支持二次开发之日起,最传统的与SharePoint交互的方式就是SharePoint服务器端编程模型。所有服务器端的对象都是以SP打头。比如SPSite, SPWeb.
2) 自SharePoint 2010开始,SharePoint引入了CSOM访问模式 ( Client-side object model),这样对于SharePoint对象的访问代码,不再局限于一定要运行在SharePoint Server端,而是通过客户端发出请求,从而实现对SharePoint服务器的访问。
在SharePoint2010中, 还只是支持.NET的客户端。SharePoint的客户端对象实际上和其服务器端对象基本是一一对应的关系,只是去掉了SP的前缀。比如服务器端的网站集为SPSite,那么客户端为Site。
只所以提出CSOM的访问模式,是因为SharePoint已然成为一个平台,需要和其他的系统进行交互;同时,如果直接在SharePoint 服务器上运行自定义代码对SharePoint服务器对象进行访问的话,如果代码质量不高,会导致SharePoint性能急剧下降。而有些不理解的客户,会怪罪SharePoint产品的问题。 为了缓解这个问题,在服务器端编程模型中, 除了SharePoint场解决方案外, 我们还引入了SharePoint 沙盒解决方案(Sandbox solution)。
在沙盒解决方案中,客户自定义的服务器端代码运行在单独的进程中,而和SharePoint的独立应用程序池进程w3wp.exe 隔离开来,从而一定程度上减轻对SharePoint服务器的影响。沙盒解决方案的SharePoint结构如下:
3) 自SharePoint 2010起,我们还引入了SharePoint Powershell。 这样,开发者可以通过编写PowerShell script来实现对SharePoint的访问和设置。
4)自SharePoint 2013起,除了支持.NET客户端外,其还引入了REST的支持,从而实现对多种类型客户端的支持。
5)在SharePoint 2013起,SharePoint还引入了新的概念SharPoint App (SharePoint 程序)。相比于传统SharePoint中的web part, SharePoint App是一种轻量级的程序, 其是通过CSOM的方式来实现对SharePoint的访问。因此,SharePoint App可以通过3种类型进行部署:
a) SharePoint Host ( 即SharePoint web app部署在SharePoint Server上,该web app只能通过JS, CSS, HTML5这些客户端技术来访问SharePoint)
b) Auto-Host ( 即SharePoint web app自动部署在SharePoint为你自动创建的Windows Azure Websites上,部署在Windows Azure Websites上的web app可以通过.NET等技术和SharePoint交互)
c) Provider host (即SharePoint web app部署在自定义的任何Server上,可以是Windows Azure, 也可以是你的on-premise server,或者是你的PHP等,可以通过任何技术和SharePoint交互)
在我看来, Microsoft是要把SharePoint打造成一个协作平台的入口。通过该统一入口,我们可以把SharePoint和其他系统集成起来,而这些所谓的“其他系统”可能是部署在任何地方的企业应用。当然,Microsoft是希望“其他系统”部署在Microsoft Azure上,从而打造一个全部基于Windows Azure的以SharePoint为入口的平台。
所以,那些认为SharePoint Online只是一个文档存储中心的客户,似乎有些小看SharePoint了哦 :)
相关资源:
Microsoft Office 365免费试用链接:
https://portal.office.com/Signup/MainSignUp15.aspx?Dap=False&QuoteId=79a957e9-ad59-4d82-b787-a46955934171&ali=1&alo=1&lc=1033