微軟Sharepoint的一些缺點

轉：http://bbs.tianya.cn/post-144-566491-1.shtml

微軟Sharepoint的一些缺點（一）

微軟Sharepoint的一些缺點
　　
　　關於SharePoint，它是在文件管理平臺上構建起來的，加入簡單工作流功能的web系統。它完全基於微軟體系架構，好處是與Office結合緊密，缺點是相容性不夠，過分依賴微軟執行環境。
　　
　　Sharepoint的工作流，只支援簡單的順序操作邏輯。如果涉及到退回、分支、迴圈、會籤等複雜應用，就必須藉助Visual Studio，完全通過編碼來實現。
　　
　　如果需要編碼，就需要掌握Windows WorkFlow Fundation, Web  Part, ASP.NET, CAML, Infopath以及Windows Sharepoint Server等大量內容，而且相關中文資料很少，會造成極高的二次開發成本。
　　
　　最後，Sharepoint還存在難以控制頁面欄位許可權，效能瓶頸，以及不支援分頁調整等一些硬傷，具體可參見下面資料。以下內容全部摘自網友評論。
　　
　　
　　關於效能：
　　1. 上海新世界地產用Sharepoint失敗，因為執行很慢,維護成本非常高
　　2. 除錯時注意兩件事，一個是計算機需要很多RAM，第二是SharePoint執行很慢，要耐心。
　　3. “在企業層面上，還有一定的領域有待於進一步開發，例如，在備份、效能和歸檔方面，我希望藉助於其它的供應商參與進來” Bryne說。
　　
　　關於產品定位：
　　1. Sharepoint的工作流可以配置簡單的，但是遇到複雜的需要自己去寫程式，當然這是可以解決一部分業務工作流，但不是長久之計。
　　2. 可能有些人還不知道，SharePoint是一個在文件管理平臺上構建起來的、基於Web的辦公套件。
　　3. Sharepoint可以當一個門戶、文件管理、一些簡單的oa辦公流程
　　 “當你安裝並實施了SharePoint以後，就可以有一些基本檔案的共享，但它不適合於更為複雜的文件管理。管理文件需要複雜的企業分類或更為複雜的有規則的工作流，那麼SharePoint就有點落後了”。
　　
　　關於工作流：
　　1. 採用SharePoint Designer設計工作流的優點是操作簡單，無須編譯和部署，缺點是隻能實現順序操作邏輯，無法實現退回等迴圈邏輯，審批介面自動生成，也無法實現一些複雜的操作。如果需要這些，必須通過Visual Studio程式設計實現。
　　2. 第一種需求oa系統，完全可以使用sps的列表和文件庫來開發，一般的公文流轉和工作流都不需要編寫程式碼。這種系統如果對資料處理比較大的話就不是很方便，例如，報銷單據的業務，用列表可以很方便開發報銷的業務模組，但如果客戶提出統計某部門某段時間的報銷費用，或者對部門進行成本核算(用到報銷的資料)。像這類業務使用列表來處理就很不靈活了。一旦有這樣的需求原來用列表設計的模組可能需要改動來適應這種複雜的需求。
　　SharePoint帶給你的意外收穫是你可以得到一份支出單以及不用供應商，很容易向你的經理彙報情況。這一點是好的。但是，你還需要一個NET開發者進入到系統裡。千萬不要對培訓內部員工有過高的希望。
　　3. SharePoint的工作流可以說是非常的脆弱，如果想在SharePoint上實現中國式的文件流轉，我估計頭上的白頭髮又會增加不少。不知道微軟是怎麼搞的，SharePoint這麼優秀的解決方案，但工作流設計真的太不入流了，至少不滿足中國國情。

 

 

 

 

微軟Sharepoint的一些缺點（二）

 

微軟Sharepoint的一些缺點
　　
　　關於二次開發：
　　1. 最近有一個專案是針對基於Windows Sharepoint Server, 並利用Microsoft Office Sharepoint Server2007和Design的開發和部署(其實我對這個專案是頗有微辭的, 首先對於這類技術的整合還沒有掌握, 專案書上說是配置佔70%以上, 其實不然以這樣的要求顯然開發佔了70%以上). 並且我對這種Microsoft極度推崇的技術也是心存一些不滿的. 首先它的內容更廣一些,不僅設計了Windows WorkFlow Fundation, Web  Part, ASP.NET 2.0, CAML, Infopath以及Windows Sharepoint Server等大量內容還有許多企業應用的概念. 並與Office系列產品有高度整合. 這對於一個開發人員來說需要掌握更多的技術特性. 其實光是精通其中兩樣已經是很不容易的一回事了. 基於它的二次開發難度較大, 並且許多預設提供使用者的操作方式都不是傳統的Web使用者操作習慣. 說穿了只是Microsoft想要捆綁它的一整套產品銷售, 賣給那些政府或者大型企業而已. 哎! 感嘆做為開發人員, 不是每個專案都能選擇讓你使用你擅長的喜愛的技術.
　　2. 問題在於微軟產品的高度整合和依賴性，不僅給使用者的應用成本帶來了約束，而且還限制了微軟協同系統在非微軟主流使用者範圍內的推廣；完全基於微軟體系架構，具有完整的技術體系和可靠的應用保障，但同時也存在相容性不夠，過分依賴微軟執行環境的缺點。另外，由於作業系統可靠性及原始碼不開放等問題，對於複雜的大型應用和要求很高的環境，應用會受到影響。
　　
　　
　　關於許可權：
　　1. 在MOSS/Sharepoint  控制檢視頁面訪問許可權開發的問題，這些功能通過sharepoint已有功能是很難解決的
　　2. 在二次開發上，SharePoint webpart定製還是比較難，定製一個自己滿意的webpart真的很困難，其中webpart的許可權機制真的讓人厭煩，這一點我深有體會。還有SharePoint的外觀定製也非常困難，如果經驗不太豐富的開發者很難定製出比較漂亮的介面，我想這和sharepoint定位有關，因為它主要是用來定製內部入口網站。還有sharepoint的使用者是與NT域相結合，因此如果想用sharepoint來進行外部網站開發，只有採用匿名訪問機制了。SharePoint Portal Server 2003的許可權只能控制到區域，而不能控制到具體的檔案和資料夾，在區域下面進行專案管理時，只有採取為具體專案建立子站點的方式，這樣就讓終端使用者使用時感到很茫然。
　　
　　一些具體的技術缺陷：
　　1. 如果使用SharePoint 2007作為文件管理平臺，它很讓人詬病的一點就是，SharePoint 2007將檔案本身直接儲存在SQL Server資料庫之中。雖然Windows SharePoint Services 3.0 SP1增加了一個External BLOB Storage(EBS)介面，但是微軟並沒有提供實現，而是需要開發人員自己來實現它。
　　2. sharepoint的部分應用缺點:
　　(1) List分頁
　　List的分頁只支援“上一頁”，“下一頁”，並不支援分頁的調整。這個不太適合國內的做法。
　　(2) List的匯出功能
　　SharePoint的List支援匯出功能，裡面匯出的Excel，多2個預設的欄位，這個也還ok，但是仔細對匯出功能進行研究，發現匯出的當前檢視的所有資料資訊，即使你分頁了，或者是做過篩選，匯出的都是當前檢視的所有資料資訊。
　　(3) List檢視資訊的篩選
　　List檢視非常靈活，也非常好用，但是給使用者自己定義，這個使用者就不太樂意了。檢視的篩選資訊支援很多，但是不支援使用者和組型別包含當前使用者。所以做定向通知的時候，遇到發給一個組，就需要開發實現了。
　　如果不在AllItems頁面下的list WebPart 看不到檢視的選項，只能使用當前的檢視。
　　(4) List 之間的1：N的關係
　　如一個List儲存學生的常用資訊，一個List儲存學生對應的成績資訊。這個時候實現可以通過查閱項進行，通過查閱項只能實現一個1：1的關係，而且還要選，沒有太多實際的用處。我以前參考一些資料，實現了類似的功能，但是操作起來有點繁瑣，需要分2步進行。第一步，填寫個人資訊。第二步，填寫成績資訊。
　　(5) 文件庫
　　文件庫可以支援檔案的上傳，但是上傳上去之後，才能對文件的屬性資訊進行修改。對於中國人的習慣應該是上傳文件的同時，再填寫文件的屬性資訊。
　　文件庫不支援附件的上傳，如果希望對一個檔案進行附件的圖片的描述，這個時候就沒有什麼好辦法啦，只能通過查閱項來處理。
　　(6) 富文字欄位
　　這是一個存在很大爭議的欄位，我在這裡不也不多說。只說一些常見的問題：
　　a) 圖片的上傳
　　一般的富文字欄位
　　通過填寫圖片的路徑和描述，來實現圖片的新增功能。如果要新增圖片，必須先找一個地方進行的圖片的上傳。
　　(7) 釋出型別的富文字欄位
　　釋出型別的富文字欄位，比一般的富文字改進了很多，可以選擇相應的圖片，但是如果要上傳一個圖片，這個時候，就在彈出新的頁面進行上傳，上傳完畢之後，需要關閉當前頁面。
　　(8) 搜尋
　　搜尋功能是SharePoint中5大特點之一，但是SharePoint的搜尋功能是通過爬網爬出來的，所以針對List的某些特定欄位（大於1個）的搜尋，基本上無能為力。這個功能可以通過現有一個SmartQuery控制元件進行解決。
　　(9) 導航
　　SharePoint的頂部導航能很靈活的進行新增和刪除，但是我們在當前站點新增一個頁面，並把這個頁面新增在導航的時候，就會發現，點選頁面的導航，啟用狀態還是首頁。這個問題好像只能通過對樣式的修改進行解決。
　　(10) 樣式
　　List顯示資訊的樣式不太符合中國人
　　整個SharePoint的樣式，不太適合中國人的風格，基本上每個專案都會修改SharePoint站點的樣式
　　(11) 應用模板
　　微軟提供一些應用程式模板，基本在實際的專案中，基本上不能使用
　　(12) 許可權
　　SharePoint中的list預設會繼承整個網站集的許可權，ListItem 預設會繼承List 的許可權。當SharePoint中的使用者是以單個AD使用者加入的，並賦予許可權，這個時候，List 和ListItem的許可權記錄會對對應使用者和網站賦予許可權的組，導致資料量很大。如果List 和 ListItem 都很大（30-50個list），這個時候想刪除使用者基本上不太可能了。
　　如果不給使用者和組賦予網站集的許可權，當在一個List或ListItem 賦予了使用者和組的許可權，在網站上就會出現一條相應的記錄。
　　
　　(13) 資料的刪除
　　如果一個List的資料資訊到了10w，你刪除這個站點，就刪不了了。
　　使用者許可權在List中出現次數過多，也會導致使用者無法刪除。
　　如果想對整個基於sharepoint平臺的網站實現多語言版，不敢說是奢望，至少我至今還沒有找到比較好的解決辦法。
　　總的說來，sharepoint只比較適合做知識門戶的開發，前提是你不嫌它太貴，因為硬體和軟體投資都比較大。