在聊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免费试用链接：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。