当前位置: 首页 > 工具软件 > DotNetNuke > 使用案例 >

DotNetNuke疑惑

洪逸清
2023-12-01
类似一种准入限制,最近客户提出了近一段时间内的开发框架:使用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”,要不然我会严重抗议了。

转载于:https://www.cnblogs.com/Barton131420/archive/2006/10/04/521014.html

 类似资料: