業務相關的SharePoint開發和維護常用方案

本文談談本文人對SharePoint中業務相關的開發/維護的一些感想和可行方案。

1、業務相關的SharePoint應用概述

一般來講，SharePoint主要被用作企業級的KM Portal。當SPS只被用作KM的時候，其內建的整合到AD的人員管理、基於subarea、subsite、list、document library，bbs等built-in的組件可以比較自然的映射到企業現實中的人員、組織圖、資源、討論等等。但是，現實中，也有不少基於SPS這個平台進行二次開發的非KM應用系統，這類系統中，由於不可避免地要涉及到很多業務相關的邏輯，使得SPS中built-in的這些組件不足以處理這些額外的商務邏輯，那麼此時，可以有哪些方案來進行二次開發呢？

2、SharePoint二次開發方案

2.1 JavaScript + Custom Data View + SPS WebService

首先，如果商務邏輯比較簡單的話，特別當資料處理和對現實和操作的look&feel，要求不是很複雜，並且，也並不十分介意在用戶端暴露商務邏輯的話，直接通過FrontPage定製SPS中的頁面，通過Custom Data View和SPS提供的Web Servise作為資料的讀寫介面，配合JavaScript來處理資料並負責定製的顯示介面，通常就能夠滿足要求。

這種方案的好處是沒有用到任何的外部資源，可以線上開發、部署和維護，也非常方便打包和遷移，因此，一般來講是比較被推薦的方案。

2.2 External Web Service Site

如果，業務更複雜一些，特別對於資料的處理能力和安全性要求更高（不想把商務規則暴露在Client端），則相對於方案2.1，一個簡單的辦法是可以將對業務處理部分移到服務端，一種方案就是建立一個額外的Web Service網站，專門用以處理這類業務，並通過Web Service介面與SPS通訊。

這種方案新增了開發和維護一個附加的獨立Web Service網站的負擔，但是可以獲得2.1中的絕大多數好處，並且獲得了更強的資料處理能力和安全性。當然，這個額外的網站不必須基於.NET Framework，也可以部署在在任何的遠程伺服器。

2.3 External Web Application Site

方案2.2能夠解決2.1的“在用戶端暴露商務邏輯”的安全性問題，但是，不能解決“提供複雜的顯示介面和輸入驗證”的問題，這個方案則考慮將“提供複雜的顯示介面和輸入驗證”的能力轉移到一個外部的Web Application去，嵌入原有的SPS網站去。Application和SPS則同樣通過SPS Web Service進行通訊。

不過，這樣做雖然能夠解決“提供複雜的顯示介面和輸入驗證”的問題，但是，卻有可能對維護造成一些問題，主要是SPS網站的list和外部網站的一致性問題，因為，SPS中list的列可以自由定製，但是，如果業務和現實依賴一個外部網站的話，這種定製就被極大的限制了，因為，外部網站將不再能確定它要處理的某些資源是否還和設計時保持一致。但不管怎麼說，只要合理的對定製進行規範，這也是一個可行的方案。

2.4 Custom Web Part

看到以上的三個方案，很多人可能就在奇怪怎麼不說Web Part，呵呵，我這就說到。Web Part在SPS開發中，似乎處於一個比較尷尬的境地，雖然它的功能很強，理論上自訂的Web Part可以處理任意複雜的商務邏輯和顯示效果。

但是在實際的開發中，卻往往是最後一兩個被考慮的方案，究其原因就是，最重要的就是Custom Web Part的部署麻煩，並且，牽一髮而動全身，可能會影響到整個網站的其它部分的運行，一個小錯誤可能導致整個頁面崩潰，而且，往往很多錯誤是設計時不能檢測到的，安全性和操作許可權也是個大問題，總之，列舉缺點真的很容易，因為實在很多。還有是特別是不利於維護，如果要為已有的系統擴充附加功能或修改已有的錯誤，又會一次次的陷入部署、調式的泥潭。所以，Web Part方式往往在以上的方案不能解決問題時才被考慮。當然，從另一個角度來講，如果部署、維護的成本相對較低，或商務邏輯和顯示介面極其複雜的話，則也可能優先考慮Custom Web Part方案。

3、總結

綜上所述，按照業務需求的複雜程度，從2.1到2.4的方案應該是可以滿足絕大多數需求的，條件許可的話，一般來講，應儘可能選擇靠前的方案。

當然，對於任何的應用情境，都要具體問題具體分析，本文只是提出一些並不完全的建議，開發人員的經驗和能力，已有的可重用的資源等等，往往同樣能左右可種解決方案的選擇！

//文章結束