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