我为什么选择SharePoint Framework （SPFx）

        SharePoint从诞生到现在已经十多年了，我是从2009年WSS 3.0和SharePoint 2007时代开始SharePoint研发的，到今天也要十年了。十年来经历了SharePoint的不断变迁，所做过的产品也不停地随之升级换代，从SharePoint 2007， SharePoint 2010， SharePoint 2013, SharePoint 2016一直到今天的Office 365上的SharePoint Online。开发平台从.net 2.0到.net3.0再到.net 4.6，开发模式从server端开发到沙盒开发到Add-in开发再到SharePoint Framework开发，人也从二十来岁的小伙子变成了奔四的大叔。一路走来感慨良多。

        还记得刚刚接触SharePoint 2007时，蓝色的界面让我想起了老旧的windows开机界面，但是灵活的list，view，content type这些概念却需要我花上几天的时间来了解和熟悉。依然记得自己的第一个webpart运行起来时的那种开心的感觉，也还记得了解到SharePoint的数据库的表结构时的那种惊讶。我曾被SharePoint 2010带来的全新Ribbon UI震惊过，也曾在支持Ribbon UI的过程中挣扎过。我曾在SharePoint 2010上写过沙盒解决方案，也曾因为沙盒的限制太多而抱怨。微软从SharePoint 2010开始支持CSOM和JSOM，为后来的客户端编程打下了基础。随着微软的Office 365云端战略的全面开启，从SharePoint 2013开始引入了App和Add-in的概念（这里Add-in特指那些SharePoint hosted或者provider hosted的Add-in），广大开发者可以将自己开发的Add-in上传到Office Store中去销售。而到了SharePoint 2016，支持本地和云端混合部署，Office 365已经成为主要发展方向，SharePoint Server会不会还有下一个版本也尚未可知了。

        SharePoint的每一次大版本升级都令人耳目一新，UI好像完全换了样子，但是基本概念和内在逻辑结构仍然岿然不动。这大概就是我在变幻无常的IT界里，内心里一直追求的永恒，像极了纷繁多样的信息世界，还是建立在冯诺依曼体系上一样。不过这个体系可能要被打破了，去年微软已经开始推出量子计算机了，下图是我在微软Ignite大会上拍的量子计算机模型：

        不多说了，还是回到今天的主题，作为一个老SharePoint开发者为什么要选择SPFx? 其实从SharePoint 2013支持App开始，很多人就面临着两种选择，一种是继续进行on-premise服务器端的开发，一种是转向客户端开发。我虽然转向了客户端开发，也发布过Add-in，然而发现客户端开发并不容易：

        首先，SharePoint Online开发不再支持服务器端编程模式，也不使用沙盒解决方案，之前的服务器端开发经验用不上了。

        其次，使用Add-in的开发方式，由于代码隔离，导致身份认证复杂，也不能使用上下文。与Add-in相比SPFx的一个明显的优势是不再使用iframe，并且可以使用上下文。Add-in并不适合对SharePoint Online本身功能或者UI的扩展，而更适合执行一些重量级的服务或者与其他系统集成。另外Office Store中Add-in的license方式也不够灵活，多数Add-in都很老旧，下载和评论的人都寥寥无几。对于开发者来说，Provider-hosted需要额外的Server来支撑，也很大地增加了不必要的开发成本。

        第三，使用js/css嵌入的方式，部署起来麻烦，js代码对页面DOM的直接操作，有可能被用户修改，会造成升级维护困难，代码可能被No Script的配置禁止运行，而且SharePoint Online的升级和改动很可能会影响嵌入的代码。

       第四，使用Rest API，JSOM，CSOM等等，这些都是在SharePoint之“外”做一些操作，而不是在SharePoint之“上”做的操作，不能说是对SharePoint做了扩展，而只是使用SharePoint的功能。

        总之对于SharePoint开发者来说，转向云端之后，开发的成本增加了，开发的积极性降低了。

        为了解决这些问题，微软推出了SharePoint Framework，这是一个与以往不同的新的开发模式。

        首先，它是一个现代化和标准化的框架。提供了从开发，测试到部署的一整套方案。例如使用Yeoman模板创建项目，使用Gulp来调试，还提供了基于React的标准Fabric UI控件。为开发者提供了极大的方便。下图是SPFx开发客户端webpart的过程（来自微软文档）：

        其次，它采用了最新的前端开发技术栈，基于开源的前端开发工具，支持不同的前端开发框架（React, Knockout, Angular, Handlebars, jQuery 等等），并且跨平台。从下图可以看到SPFx所使用的前端技术：

        第三，它为开发者和企业提供了一系列新功能用来扩展SharePoint Online，例如可以使用当前的上下文，所以SPFx也被称作客户端的full trust开发模式。SPFx的核心功能如下（来自微软文档）：

• 没有iFrame，在浏览器当前登陆用户的上下文中运行。
• SPFx控件在正常页面的DOM中被渲染。
• SPFx控件是响应式和可访问的。
• SPFx可以访问页面生命周期，包括渲染加载、序列化、反序列化和配置变更。
• 支持多种前端框架，例如但不限于React、Handlebars、Knockout、Angular等。
• 基于开源客户端开发工具，比如npm、TypeScript、Yeoman、gulp等。
• 性能可靠
• 终端用户可以在所有的网站（包括自服务网站、个人网站、组网站）使用经过租户管理员批准的SPFx客户端解决方案。
• 解决方案可以部署在传统的Web部件、发布页面和现代页面。
• 运行时模型在脚本编辑器Web部件做了改进。包含了稳定的客户端API，一个Http客户端对象来处理SharePoint和Office 365的验证，上下文相关的信息，简单的属性定义，配置等。

        对比以往的开发模式，SPFx更适合对于SharePoint Online UI的扩展，例如添加一个Command，更改页面样式，创建webpart，自定义column展示方式等这些我们已经非常熟悉的“传统”功能的开发。使用SPFx让我感觉熟悉的SharePoint又回来了:-) 。所以，最新的前端技术，方便而且强大的开发模式，标准控件库等等这些，让我选择了SharePoint Framework。

        当然SPFx也是有缺点的，例如需要学习新的前端技术，例如SPFx还仍旧处在变化和发展中，而且变化很快。例如因为可以使用上下文，意味着它可以做当前用户权限下可以做的所有事情，增加了安全的风险。例如SPFx更适合于UI的定制化而对例如Event Handler，Workflow等无能为力。但是这些与SPFx带来的便利相比都是可以克服的。可以说SPFx的出现是对SharePoint Online开发的一次很大的促进，我相信会有越来越多的SPFx插件出现的。我也正在学习SPFx，对SPFx的了解还不够深入，希望有越来越多的朋友可以一起交流经验。

        十年回首，感谢SharePoint带给我的一切，也感谢CSDN论坛上的朋友，尤其是SharePoint板块的牛人们给我的帮助。不忘初心，方得始终，希望自己在下一个十年里，依旧与SharePoint为伴，依旧与热爱SharePoint的朋友为伴，一起在即将老去的年华里，活出精彩的自己。