DotNetNuke疑惑

類似一種准入限制，最近客戶提出了近一段時間內的開發框架：使用DNN和Atlas。我除了鬱悶，無話可說。我只能在兩者中作出選擇：一是可以拂袖而去，從而放棄我對我所服務的公司的一貫承諾；一是可以委曲求全，繼續在鬱悶中承認眼前商業社會的現實。
對於Atlas我一直備加關注，就象當年一直備加關注Orcas一樣。但“Atlas”還只是一個代號，我無法想象將一個還在代號狀態的東西用在項目中。而對於DNN我卻是相當的抵觸。雖然從IBuySpy時代就有所接觸，瞭解其中的一些表面的東西，但一直對這個東西沒有什麼興趣。看到中國DNN網站自詡爲“幾近完美的內容管理系統”，我滿身的雞皮疙瘩。雖然我也會比較在意Microsoft的認可，但是我決不會故作媚態。
用戶就是上帝，就是商業利益，我暫時還無法迴避。近日花了些時間研究，未曾想，越是研究，疑惑越多。
疑惑一：爲什麼沒有C#開發者研究DNN？
雖然.net是沒有語言壁壘的，但是DNN有，因爲DNN提供的網站模板還只有VisualBasic。其實將DNN全面移植到C#並且提供C#的網站模板並不是一件難事。但是的確沒有聽說有人在做，就是說我還沒有看到C#開發者來花時間研究DNN。那麼，DNN就成爲一個VisualBasic者建立的一個自娛自樂的天地了。
疑惑二：DNN的設計及代碼質量是否可取？
大略看了一下DNN的代碼，覺得作爲《.net設計規範》的反面教程是再合適不過了。所以我估計.net的設計者們並不會看好DNN，因此Microsoft不太可能通過某種方式收編DNN。我隨便舉出幾點：(1)DNN的接口設計不夠完美，很多功能是通過單一接口來完成而不是通過多個接口的協作來完成。這是典型的“冒面向對象之名行結構化編程之實”的表現。因爲這種設計無法按需要實現不同層次的多態。(2)DNN接口過於雍腫，例如DataProvider類一共提供了225個public的抽象方法供派生類實現。這種方式真是令人驚奇！可想而知，隨着DNN功能的不斷升級，這些接口也必須通過不斷地增加方法來隨之升級。這種設計的草率貫穿DNN的整個框架之中。
疑惑三：DNN爲什麼不簽名？
DNN和Microsoft企業庫一樣沒有提供簽名，這樣會引發一系列問題。雖然用戶加上自己的簽名是不困難的。但是10000個DNN的使用者不得不重複10000次這樣的過程。
最討厭中國DNN網站和DNN官方網站將Taiwan列爲一個國家。還好新版本的DNN中的CountryListBox將“臺灣”列爲“Taiwan, Province of China”，要不然我會嚴重抗議了。