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

任澤華Ryan發表於2016-04-17
模式

前言

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

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

相關文章