前言

阅读目录

1. Office 365 Addin案例
2. Office 365 Provider案例
3. Office 365 开发模式特点分析
4. Office 365 开发模式应用场景分析

正文

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

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模式优势：

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

Addin模式缺点：

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

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

Provider模式优势：

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

Provider模式缺点：

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

---

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