[ Office 365 開發系列 ] 開發模式分析

前言

本文完全原創，轉載請說明出處，希望對大家有用。

在正式開發Office 365應用前，我們先了解一下Office 365的開發模式，根據不同的應用場景，我們選擇最適合的開發模式。

閱讀目錄

1. Office 365 Addin案例
2. Office 365 Provider案例
3. Office 365 開發模式特點分析
4. 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模式優勢：

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 開發模式應用場景分析

終於把前面那么多話寫完了。說到底，模式雖然是固定的幾類，但實際使用中，我們通常會混合使用，下面我們來討論幾種應用場景：

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應用開發過程中需要用到的功能點進行逐一分析和實踐，希望大家繼續關注。