Net基础:对DNN在国内的影响及其弊端的思考

毋容置疑，DNN是在微软社区下的一个最大（牛）的开源社区，DNN也是Nuke系列里感觉做的最好用，最方便的一个，目前也一直处于发展阶段。相对于最初的IBuyPortal原型，无论在应用和性能，都已经有了一个质的飞跃。

但在国内DNN似乎处于一个比较尴尬的局面，刚开始挺有热情，觉得似乎这是一个无所不能的Web 2.0产品,但接触了一段时间就对此诟病不已。我想不妨在此列举一些DNN在国内突出的弊端:（个人观点，仅供参考）

• 使用习惯：我想这应该是大家最有体会的一点吧，在此我不妨给一个例子，一个客户很看重DNN，觉得用DNN搭建社区会很方便，以后升级增加功能还极其方便，无非就是增加一个类似插件的Module ( Plus)。但我们给客户把社区和论坛搭建起来之后,光是论坛测试修改就让客户觉得焦头烂额，比如没有论坛斑竹(因为国外只有Moderator的概念),没有积分功能，没有论坛短信功能等等，而这是国内任何一个成品的论坛都具有的。最终客户放弃了DNN，转而使用其他国内的论坛产品。是的，因为不管是DNN本身还是其核心模块都是国外理念的产物，存在如此迥异的使用习惯在内，这样我们如果只是纯粹的照搬过来的话，那是让客户感觉很别扭。
• 入门的门槛：DNN整个工程是如此的庞大，新手如果想一下对DNN开发模块或皮肤，那必须得了解很多DNN引进的概念，那可不是通用的，而是DNN自己的设计理念。而你想选择DNN作为你的开发平台，这些是必须深入研究的。比如DNN核心框架，皮肤概念，DAL+ 等等，光是DNN官方网站的文档就有几十份，光是看也很费事而费劲（因为是All English ）,没有几个月你恐怕还是对DNN懵懵懂懂。就举skin为例，如果你想制作skin，没问题，你可以在原来基础（或免费skin）上修改，可能1-2小时就能制作出你想要的效果，但如果你想开发专业的skin，你至少得理解DNN皮肤机制，最好还得懂得一些编程，而这是美工所不愿的。
• 可移植性: 官方版本只支持MS SQL，而且MS SQL存储过程绑定，这些需要做大量的工作才能扩展的它的可移植性。本身DNN可扩展在各个数据库下使用，可目前我尚未看到存在所谓其他数据库的DataProvider。（似乎有Access DataProvider,我记不清了）
• 社区氛围：我想这也是DNN在国内如此受到冷淡的原因吧。我想这个是大家都明白的。
• 性能：这是DNN的最大瓶颈，也是大家抛弃DNN的主要原因。因为DNN引入了skin机制，动态加载页面元素，页面中每个模块所在的容器都可以有自己的skin,页面也有自己的skin,设想一下，最极端的做法，一个平常的首页存在10个模块，每个模块有自己的skin,页面也有一个skin,那就是加载该首页时，DNN需要寻找到11个skin的文件，然后把对应的skin标签（mark-up）替代为页面显示的元素，如此一个遍历过程就能让你的页面可能在2分钟之内都是一片空白(在国内的带宽情况的设想),这种情况下还没包括你模块可能需要处理的业务逻辑处理。当然值得安慰的是，DNN一直在性能优化上付出很多的尝试和努力，比如缓存机制，HttpCompression, skin的CSS化等等。但这一过程还需要更好的解决方案的出台，比如页面静态化处理。
• 所谓Web 2.0的应用：是的,这是DNN所标榜的，也实现了一些超酷的效果，比如模块插件式开发，skin主题的应用，页面拖拽等等。但当你深入了解DNN核心模块，你会发现里边全是Table的堆积，全然没有Web 2.0所推崇的CSS控制。而且数据大部分都在页面绑定，充斥着"" .
  

写到这，大家是不是觉得我对DNN也很唾弃，可相反，我很钟情DNN，我也很看好DNN，DNN将来会有一个辉煌的时期并会成为一个成熟的Web 2.0宠儿.