写在DotNetNuke即将迎来6时代之际

      DotNetNuke即将迎来它的6时代了。一个最大改变，无疑是将代码全面转换为C#了。记得很久以前Shaun Walker还写文章说我们为什么不用C#。想不到还是顶不住民众的呼声，终于做出了一个艰难的决定。至于为什么要转，我倒并不觉得是因为VB.NET和C#之间有多大差别，而是用C#的程序员明显比VB.NET的多，随着时间的推移这个趋势越来越明显。所以DNN为了吸引更多的开发人员加入不得不转。我一直都有这么一个观念，一个开源框架的成功并不仅依靠自己的功能有多强大，而是在于是否能够提供一个良好的可扩充的平台，来吸引更多的开发人员加入。只有开发人员多了，才能无限的扩充其功能，从而满足更多的客户需要。DNN的成功正在与此，要想继续保持成功，那还是需要踏踏实实的做好搭平台的工作。转变编程语言，我想也正是基于这个考虑吧。

 

      和DNN打交道也有很多年，优点就不说了，那无疑是强大而优秀的。谈两点不足的地方吧，希望能在6时代有所改进。首先，我认为如果用DNN给客户做项目，有两种客户比较适合。一是要求不高，基本上能满足功能就满意了的。这种客户用DNN最好了，拼拼凑凑一个网站就可以搞好，几乎没有开发成本。另外一种是DIY思想很强的客户，喜欢自己加加页面，添些东西，换换皮肤之类的。DNN也很适合这类客户了，充分满足其DIY的欲望。但是DNN就怕遇到一种用户，他们要求很高，但动手能力不强。有时候这些用户对一些界面的要求，导致要重写很多现有模块的代码，从而使得模块的复用性不高，这也十分违背DNN的初衷。其实这些客户对功能到没有什么改动，仅仅是一些界面上的调整。如果DNN能提供一种细化到模块的皮肤机制，就可以很好的满足这类要求。这样就可以在不改的程序代码的情况下在，满足用户的多样化界面需求。 其次，DNN的前台代码很不简洁，十分不利于代码的前台调优，特别是客户对前台代码和SEO很看重的时候，DNN就完全不能满足这些要求了。一看长长的ViewState就让人晕倒，这也许是asp.net web forms程序的通病吧。DNN会转向 ASP.NET MVC 吗？虽然之前Shaun Walker也写过文章说过不会转为MVC，但是。。。。还是拭目以待吧。

 

     最后想谈一下对DNN6时代的期待， 我觉得DNN在6时代需要内嵌一个类似App Store功能。能够完成模块的推广、介绍、购买、一键安装、升级提醒等功能。如今应用程序商店都这么流行了DNN不会不与时俱进吧。