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

时间:2024-03-25 11:36:26

前言

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

在正式开发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:
[ Office 365 开发系列 ] 开发模式分析
Bing Map通过获取Excel表格中的城市数据,在Excel中呈现了一幅地图报表,方便用户快速简单的创建直观的地图报表。简单一看,发现确实让用户使用起来简单不少啊,不过开发应用的人员不一定那么轻松,至少你要有个地图。再看一个Outlook的插件,FindTime:
[ Office 365 开发系列 ] 开发模式分析
FindTime是为了解决在发起会议过程中,查看各个参会人的空余时间,有效的协调各个与会人的会议时间。
怎么样,有没有感受到Addin带来的好处。好吧,具体还要看有没有好的应用可以集成到组件中,像聚会邀请、问卷调查……

Office 365 Provider案例

上述开发模式是将应用作为Office 365的插件,也就意味着应用的入口在Office 365组件中,无法单独使用此应用。下面我们再来看另外一种开发模式(Provider模式),此方式的案例不是很好找(主要涉及到版权问题,担心侵权),所以就把我自己做的小产品给大家直观的看看吧:
[ Office 365 开发系列 ] 开发模式分析
首先与Addin相比,Provider模式可以独立访问,入口在应用本身而非Office 365组件中,如上图所示,我们可以更好的组织Office 365的各项功能,邮件、Lync、SharePoint Online都可以作为应用的后台服务。此方式可以作为一整套解决方案来定位,而不仅仅是一个应用。

Office 365 开发模式特点分析

看完上述案例后,我们可以针对两种开发模式进行特点分析,同时也希望有相关好的应用案例的朋友,能在评论中分享,让我们更多的了解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功能,未来升级维护成本高。

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

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 开发模式应用场景分析

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

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应用开发过程中需要用到的功能点进行逐一分析和实践,希望大家继续关注。