前言
本文完全原创，转载请说明出处，希望对大家有用。
在正式开发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应用开发过程中需要用到的功能点进行逐一分析和实践，希望大家继续关注。