原文地址是在：http://weblogs.asp.net/bsimser/archive/2006/01/31/437023.aspx
注：作者Bil Simser是一個加拿大的SharePoint Portal Server方面的MVP。
術語
在這篇文章中我想要強調的一件事情是，雖然我將通篇使用SharePoint這個術語，但是意思可能是同時指的是SPS和WSS的功能。也請注意，這篇文章大部分都是在討論當前版本的DotNetNuke（3.2.2和4.x）以及SharePoint（SPS 2003和WSS 2.0）。
DotNetNuke
微 軟發佈了ASP.NET，人們也看到了它的潛力，但是人們並不能完全的知道如何去使用它。我們需要使用這個新的工具去重新開發我們老的ASP程序嗎？我們 具體如何做？由於這個原因，任何人構建一個"門戶"應用必須都自己來手工創建。每個人都需要做這個工作，我已經看到過無數次的類似行爲，使用ASP或者 ASP.NET完全從底層開始做起。當然，我也曾經見過類似"WebPart"這樣的實現，讓人們可以直接的拖到頁面上。
到 了DotNetNuke，這個令人驚訝的門戶系統從IBuySpy發展而來。談到這裏，我先簡短的介紹一下它的歷史。微軟爲了展示Asp.NET的能力， 曾經做了一個門戶系統的示範程序，名字叫做IBuySpy，一個虛擬的網上商店系統，銷售一些間諜用品，例如X光眼鏡，隱藏的麥克風等等。這個應用程序有 一些關鍵性的特點去展示ASP.NET的動態模塊功能，例如通過添加"模塊"到頁面上創建內容，基與用戶權限來控制功能的可見性，和提供一個簡單的站點導 航（不需要任何手工編輯頁面的工作）。IBuySpy是一個起步教程，讓人們可以構建他們自己的銷售系統和門戶系統，非常美妙。
2002 年11月份，Shawn Walker利用這些代碼創建了一個增強的VB.NET實現，名字叫做IBuySpyWorkshop。開發社區開始口吐百沫（當我們看到一個非常酷的東 西時經常會這樣），成千上萬的人下載了這些代碼。這個巨大的成功終於導致了這個項目發展出了自己的獨立產品，並被改名爲DotNetNuke。從那以後， 一些其它的人也從IBuySpy發展出了一些自己的項目或產品，例如Rainbow等等。無論是DNN或者SharePoint都擁有許多自己獨特的優點和缺點。讓我們來看看他們到底有那些不同或類似，和具體的原因。
模塊（Modules） vs. WEB部件（Web Parts）
一個同樣的東西，雖然名字不一樣，但是他們仍然指的是同樣的東西。DotNetNuke裏面叫做模塊（Modules），而SharePoint叫他們是WEB部件（WebParts），它們本質上同一個事物。由一個.NET程序集（或一組程序集）完成某個功能的業務邏輯和界面展現，並可以被放置在門戶的任何地方。
一個SharePoint的WEB部件，就好象DNN的模塊，是一個組件並且可以被使用在站點上。在DNN中，你可以添加它們到一個頁面上，而在SharePoint裏，你可以添加他們到WEB部件頁上。以及它們提供的許多同樣的概念，比如位置，個性化，最小化能力等等。DNN有一些更強大一些的功能，例如RSS訂閱，自定義容器和打印能力等。而在下一版本的SharePoint中，RSS將被集成到整個系統，所以SharePoint的WEB部件也可以和DNN的一樣被訂閱。
而SharePoint最大超過DNN的好處是DNN的模塊只能被使用在DNN上，而SharePoint的WEB部件則可以被使用在其它任何採用WSS作爲基礎開發的系統之上（Porject Server等）。這個功能實際上將會下一代的Asp.Net 採用，用Asp.Net編寫的Web部件能夠被同時使用在Asp.Net應用程序和SharePoint上。所以你可以說只要暴露出業務邏輯服務接口，你就可以移動模塊到任何的SharePoint服務器上而不需要做修改。不過需要記得這取決於你如何編寫自己的WEB部件，但是我沒有見過DNN模塊被使用在除了DNN以外的任何其它的系統，即使是4.x的DNN是採用Asp.Net 2.0開發的。
通過研究SharePoint的WEB 部件，我不得不說添加一個模塊到DNN簡直是太方便了。基本上，你只需要打包一個模塊，然後上傳到一臺DNN主機上，就可以在所有的門戶站點中使用它了。 這一切都是由系統在運行期間完成，不需要關閉系統（包括添加一些新的表到數據庫中）。這點非常爽，雖然你可能會面對一些專門搗蛋的模塊。而在SharePoint中 這將是一個非常麻煩的工作，先添加一個程序集到BIN目錄或GAC中，然後添加一個SafeControl到Web.config配置文件中，再然後，可 能還需要使用一個IISRESET命令來重新啓動IIS系統。假如有人編寫了一個"上傳WEB部件的WEB部件"將會是一個非常酷的東西。
我將不討論開發一個模塊和WEB部件的比較，當我深入到其中時發現所有的東西都非常類似，都是同樣的概念（Asp.Net，User/Server Control等等）。
內置模塊
DotNetNuke提供了大概25個內置模塊，他們都是不屬於框架內部的，但都可以被最終用戶添加到任意的頁面上。在後期的版本中（3.x以上）提供了模板和嚮導來幫助你快速的應用一系列的頁面和皮膚到你的站點上。這點和SharePoint的站點或區域模板非常類似。SharePoint提供了一套獨立的列表或文檔庫模板，獨立於採用這些模板創建的實例。
你可能會說DNN比SharePoint擁有更多的模塊，但是你仔細研究DNN的模塊後會發現，大多數DNN的模塊都可以通過SharePoint的自定義列表或自定義視圖配置出來。下面是一個比較詳細的對照表：
|
模塊 |
DotNetNuke |
SharePoint |
備註 |
|
公告 |
有 |
有 |
非常類似，但是DNN提供了可以讓每個公告顯示時間的能力。不過WEB部件的數據視圖也可以做到這點。 |
|
標題欄（Banners） |
有 |
無 |
可以通過一些特殊的方法實現，但是比較麻煩 |
|
聯繫人 |
有 |
有 |
SharePoint勝出，它提供了更多的列，並且可以連接到Outlook。 |
|
討論板 |
有 |
有 |
兩者非常類似，平板型，並且都沒太大用處。DNN擁有一個新的核心論壇模塊，更加類似商業的論壇系統。 |
|
文檔庫 |
有 |
有 |
非常類似，但SharePoint提供了Office集成，版本控制，和簽入/簽出等功能。 |
|
事件 |
有 |
有 |
非常類似，都提供了列表和日曆視圖，重複事件，過期等等。SharePoint提供了Outlook集成，有能力爲一個事件創建一個會議工作區。 |
|
常見問題 |
有 |
無 |
可以使用自定義列表來創建，但是需要一個數據視圖WEB部件，需要Javascript編程或組視圖提供展開和收縮。 |
|
反饋 |
有 |
無 |
SharePoint可以通過WEB部件編輯器或者自定義列表來創建，但是沒有EMAIL集成。 |
|
IFrame |
有 |
有 |
SharePoint是叫做頁面查看器，WEB部件編輯器也可以通過一個URL來連接內容。 |
|
圖象庫 |
有 |
有 |
幾乎完全一樣。 |
|
連接 |
有 |
有 |
DNN擁有更加靈活的排序功能和表現形式，不過SharePoint也可以通過自定義方式來實現同樣的功能。 |
|
新聞反饋 |
有 |
無 |
需要通過第三方的WEB部件，但是也可以通過XML WEB部件和XSLT文件來完成同樣的功能。 |
|
用戶帳號 |
有 |
有 |
在SPS和WSS上有不同的訪問和表現形式，但是都非常類似。SharePoint使用活動目錄而不是自定義列表，因此沒有DNN的功能強大。 |
|
Text/HTML |
有 |
有 |
SharePoint有內容編輯WEB部件，兩者非常相似。 |
|
成員 |
有 |
有 |
這些比較並不是非常的精確，但是也非常的接近現實情況。我想說的是他們每個都有自己的優點和缺點。一個具有冒險精神的人（我不是）可能會做一個完全自定義的SharePoint模板和列表來完成標準DNN所能提供的默認功能。DNN的確有一些核心的模塊是SharePoint無法提供的，但是大部分情況下，你可以通過自定義列表來提供類似的功能。
帶上我的DNN帽子，我可以說你可以通過自定義的模塊，或者需要對DNN做一些小的修改就可以提供SharePoint所有（但不是100%）類似的功能。從根本來說，一些Office 2003的集成能力也可以通過ActiveX控件來完成，所以沒有人能說哪個功能必須要SharePoint來完成（例如，我曾經在一個標準的Asp.Net程序中提供過地址薄功能）。
唯一真正的寶石是當前SharePoint已經提供的Office集成能力，假如你大量使用微軟的產品，需要處理大量的Office文檔或者Outlook聯繫人，那麼這足夠強迫你使用SharePoint。否則你會花大量的時間去修改DNN，以提供Word集成能力（假如可以的話），允許Word可以簽入一個文檔到DNN（並不是說不可能，但是至少不是一個簡單的工作）。
可見性
這是一個SharePoint至 今還缺乏的主要功能。在SPS中，我們可以對用戶進行驗證，並使用一些安全限制來隱藏某些區域。但是更多的情況是不行（特別是在WSS中），用戶看到的東 西多於他可以使用的。這個被叫做安全裂縫，只需要向用戶顯示什麼事情他可以做，而不要讓他通過5個步驟的嚮導之後，再告訴他不具有權限去完成這個過程，這 會寧人感覺像是在進行一個賭博。
無 論如何，在DNN中，我們擁有能力去分配模塊的權限，或繼承頁面的安全設置（頁面也能分配到角色）。不能分配獨立的用戶權限。所以你不得不定義一個角色， 然後分配一個用戶給這個角色，去查看（或不能查看）某個頁面或模塊。這種權限模型非常好，並且被大量的系統採用。只像特定的成員顯示特定的信息，而在普通 情況下他們將看到的是另外一個界面，直到他們登陸系統或者取得訪問權限。
安全裂縫在下一個版本的SharePoint中仍然存在，所以DNN再一次獲勝。
自定義外觀能力
這 是一個比較棘手的比較，但是我不得不把勝利者給予DotNetNuke（至少到目前爲止）。DNN使用皮膚技術來完成自定義外觀，非常類似WSS的主題， 或在SPS中使用自定義的CSS文件。然而，DNN的皮膚技術走得前一步，可以讓你自己設計頁面的佈局，包括添加模塊和控件（比如當前日期/時間和一個登 陸控件顯示哪些用戶登陸或者一個註銷按紐）。
給DNN創建一個皮膚非常簡單，只需要花幾分鐘或幾個小時（根據你創建的皮膚的複雜性而定）。一個更酷的事情是DNN可以給每個頁面分配不同的皮膚（主要是因爲DNN使用單一頁面的程序架構）。在任何情況下，SharePoint的主題技術和DNN的皮膚技術都不是一個等級的比較，坦率的說，創建一個完全自定義的皮膚對DNN來說是一件非常容易的事情（我爲我自己的站點創建一個WSS的皮膚花了我將近一個小時）。
當然，我也不得不談到下一個版本的SharePoint將會完全利用到Asp.Net的母版頁技術。所以，界時這個比較可能要重新定義。
基礎架構
在級別上，兩者幾乎是不能比較的，SharePoint的 承載能力非常巨大（在世界範圍內，微軟自己內部運行的SPS擁有將近250000個站點）。而DNN主要是提供給愛好者，在某些情況下，他也可以被應用在 企業的內部網絡上，當然我指的並不是像IBM，波音或者國家航空航天局這樣的企業。而一個小型的擁有數百個人的公司爲什麼不行呢？
然而，隨着硬件能力的提升，你可以提升DNN的承載能力。但是並沒有類似SharePoint所提供的企業搜索，單點登陸，或分離索引等功能，這受限制於DNN的體系架構觀點。
DNN提供了許多Asp.Net提供的基礎項。例如登陸模塊。DNN提供了一個機制處理廠商廣告和收費系統。DNN也提供了處理訂閱的機制。你不得不自己在Asp.Net 2.0中自己構建這些功能（這並不是一項非常困難的工作，但是仍然需要"工作"）。
DNN最好的部分是一個標準用戶可以在外部實際的進行添加/編輯/刪除功能。你可以給他們一個演示，然後現場交給他們一個任務。你可以也可以在SharePoint中完成同樣的工作，但是因爲某些原因，大多數用戶仍然摸不着頭腦。也許是我總是面對一些比較笨的人吧。
社區
你大概會同意DotNetNuke社區遠遠大於SharePoint，DNN站點被數以千計的商業站點、社區站點和個人站點運行着，而SharePoint只有數百個。這也可能是由於免費和受費的結果。
（後面大量篇幅談及商業性問題，這裏省略）
總結
（也有大量篇幅，但是總的意思是說DNN有DNN的好處和適用情景，而SharePoint也有SharePoint的好處和適用情景。相對來說DNN更加適合外部網站，而SharePoint更加適合內部網站）。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=2163012