[ Office 365 开发系列 ] 开发模式分析

前言

本文完全原创，转载请说明出处，希望对大家有用。

在正式开发Office 365应用前，我们先了解一下Office 365的开发模式，根据不同的应用场景，我们选择最适合的开发模式。

阅读目录

Office 365 Addin案例
Office 365 Provider案例
Office 365 开发模式特点分析
Office 365 开发模式应用场景分析

正文

Office 365 的开发模式主要分为两类：

　　office 365 addin应用开发
　　office 365 provider应用开发

Office 365 Addin案例

Office 365 addin开发指在Office 365 应用组件中开发的插件，目的是为了增强或定制Office 365组件，如下图所示，我们在Excel中使用的Bing Map：

Bing Map通过获取Excel表格中的城市数据，在Excel中呈现了一幅地图报表，方便用户快速简单的创建直观的地图报表。简单一看，发现确实让用户使用起来简单不少啊，不过开发应用的人员不一定那么轻松，至少你要有个地图。再看一个Outlook的插件，FindTime：

FindTime是为了解决在发起会议过程中，查看各个参会人的空余时间，有效的协调各个与会人的会议时间。

怎么样，有没有感受到Addin带来的好处。好吧，具体还要看有没有好的应用可以集成到组件中，像聚会邀请、问卷调查……

Office 365 Provider案例

上述开发模式是将应用作为Office 365的插件，也就意味着应用的入口在Office 365组件中，无法单独使用此应用。下面我们再来看另外一种开发模式（Provider模式），此方式的案例不是很好找（主要涉及到版权问题，担心侵权），所以就把我自己做的小产品给大家直观的看看吧：

首先与Addin相比，Provider模式可以独立访问，入口在应用本身而非Office 365组件中，如上图所示，我们可以更好的组织Office 365的各项功能，邮件、Lync、SharePoint Online都可以作为应用的后台服务。此方式可以作为一整套解决方案来定位，而不仅仅是一个应用。

Office 365 开发模式特点分析

看完上述案例后，我们可以针对两种开发模式进行特点分析，同时也希望有相关好的应用案例的朋友，能在评论中分享，让我们更多的了解Office 365应用。

Addin模式下，应用入口在Office 365组件中，用户需要通过客户端访问Office 365组件，如Excel、Outlook、SharePoint Online等，在组件中操作应用。

Addin模式优势：

开发模式较Provider模式更加直接，专注于特定功能点，能较好的与Office 365组件集成。
应用无需实现以后的用户验证、用户授权以及相关界面内容，同时可以充分利用Office 365提供的众多开发API，甚至使用Office 365提供的标准页面组件。
用户部署简单，通过App Store直接加载使用，无需登录其他应用。

Addin模式缺点：

由于Addin是基于Office 365组件开发，所以入口现定于Office 365内部，导致灵活性欠佳，独立访问困难。
Addin模式需要兼容Office 365本身的显示方式，在用户体验方面灵活性较差。
Addin模式下，引导用户能力较差，无法提供整套解决方案。
Addin模式受Office 365组件本身的局限性较多，导致拓展性较差。
Addin模式依赖Office 365的OOB功能，未来升级维护成本高。

Provider模式下，应用程序的入口在应用本身，用户通过访问应用程序提供的服务，来使用Office 365的应用组件，同时应用服务可以集成其他基于SAAS模式的服务。

Provider模式优势：

灵活性高，可定位为Office 365产品平台，能较好的给用户提供整体解决方案。
用户体现性好，由于在此模式下，我们可以使用最新的前端技术，为用户带来更高的体验感受。
集成性好，由于目前用户信息化要求较高，Office 365无法满足所有的用户需求，所以我们可以在此模式下集成更多优质应用，将其与Office 365整合，实现统一解决方案。
用户粘度高，较高的产品迭代效率，会带来更高的用户黏度。

Provider模式缺点：

Provider模式下，我们会将应用作为一个独立的平台，导致我们需要做的事情也会增加很多，如用户验证、用户界面、系统管理等。
Provider模式的对于Office 365的集成在技术层面要求更加高，需要开发团队对Office 365的各个组件都有较为深入的了解。
Provider模式的应用需要更多的资源支持。
Provider模式需要引导用户通过应用平台访问，需要较好的市场推广。

Office 365 开发模式应用场景分析

终于把前面那么多话写完了。说到底，模式虽然是固定的几类，但实际使用中，我们通常会混合使用，下面我们来讨论几种应用场景：

1.　已有产品，想要把产品集成到Office 365中，如会议室预订系统、内容管理系统、CRM系统。

　　已有产品我们可以认为产品已经有完善的架构，只需在Office 365中使用该产品应用。此时我们应使用Addin模式进行开发，将现有的应用服务集成到Office 365组件中，让用户在邮件、Lync、OneDrive中使用产品服务，对已有产品缺失的云端属性进行补充。此方式可以为产品已有用户带来云端体验，同时也可以为现有Office 365用户带来新的应用功能。

2.　基于企业解决方案，用户想要迁移到Office 365中

　　基于企业解决方案，通常企业想要通过将现有私有云的解决方案迁移到Office 365云端，由于企业办公所需的门户、办公平台、HR平台以及其他的业务平台都需要集成到应用中，我们一般采用Addin模式，为用户实现多应用集成，统一的办公入口可搭建到SharePoint Online站点中。

3.　想要基于Office 365开发一套云端日常办公系统，同时有想要将其他应用，如微信、EventNote等基于SAAS的服务应用加入到平台中。

　　如果是想在Office 365平台外搭建一套日常办公平台，请选择Provider模式，将Office 365平台作为产品的一个重要部分，充分利用其功能，并加入其他的优质应用。

结束语

开发模式分析已经完成，接下来我们会正式进入实战模式，对Office 365应用开发过程中需要用到的功能点进行逐一分析和实践，希望大家继续关注。