剖析DNN架构-开篇之作

dnnsun@gmail.com — Mon, 26 May 2008 13:35:38 GMT

本Blog将新增一个栏目，暂时取名为"剖析DNN架构",名号似乎有些大了，但考虑到这也算是鞭策所写文章质量的一种手段，故最后暂且不做更改了。对于为何出现这一栏目，主要是一直以来跟一些DNN爱好者们的交流所促使的。曾有几位朋友所在公司想利用DNN这一开源平台或开发产品，或与现有系统整合，或优化框架以便满足需求等等，故他们都愿意招聘能真正担当起这一重担的“千里马”，想想这将要求所聘之人具备以下一些条件:

1) 熟悉DNN核心架构和框架脉络。
2) 有一定的架构经验，懂得设计模式相关知识。
3) 精通DNN模块开发流程及其皮肤机制。

等等，“DNN架构师”也就从此诞生了，当时我听到他们的招聘要求之后,唯一的想法是在国内，此等“千里马”实在是凤毛麟角，恐怕他们只能望梅止渴了。因为想想国内研究DNN的氛围,人气之淡，交流之稀，凭何能促进DNN这一开源平台的兴盛呢？

对于DNN入门的门槛，就我个人的观点还是蛮高的，当然你想借助DNN搭建一个网站倒是及其容易的，也就是1-3分钟即可，而目前DNN模块及其皮肤资源还是蛮多的（其中包括免费或商业的),只要你合理利用还是可以满足大部分需求的。但如果你想定制业务或布局修改的话，那就必须得了解一些编程技巧或HTML，CSS布局原理等。对于非专业人员，恐怕是力所不及的。而对于刚入门的开发人员，你需要了解的更多，其中包括DNN基本架构，模块开发流程，API调用等等，想真正开发一个高级模块，也不是一蹴而就的。最不幸的是，由于国内相关资源的欠缺，一些刚入门者屡屡碰壁也就不足为怪了，在此我还是鼓励大家,如果你想真正好DNN，那么请你耐着性子看看英文资料吧，其中包括DNN官方的第一手资料。相反，可喜的是如今大家已经逐渐看好DNN，各方面应用不断涌现，比如电子商务，游戏站点，社区论坛，ERP整合，电子政务等等，可以这么说，DNN应用在国内这一潜在市场正在形成中，群雄逐鹿，看看你是否可以在此市场中分得一杯可观的羮。

最后，再聊点本人认识的DNN，DNN可算是.net下最大的开源平台，其优势是显而易见的，其地位也是举足轻重的，DNN可谓为Microsoft也作出了相当大的贡献，想想DNN本身是VB.Net开发的，这也可以理解为留住VB开发人员的一个诱饵吧，更深的一层就是由DNN带动的.net项目不在少数，曾有官方数据对此进行佐证，可惜我没有记得链接，似乎是DNN OpenForce '07大会统计的。记得前些日子，也曾有小道消息称，Microsoft将收购DNN所属公司，将其商业化，集成到某一产品中，这可谓不振耳发聩。后来知晓此为子乌虚有，但同时也不禁为DNN未来之命运所担忧，一个纯开源的项目在"不开源"的Microsoft国度是否可以一帆风顺，茁壮成长呢？是否将半路夭折呢？是否将穷途末路呢？如今VS 2008 已粉墨登场，ASP.NET Ajax Framework也横行了半边天，如果说DNN当初的Membership,"拖拽"（clientAPI之威力)是值得炫耀的话，现在已是烟飞灰灭了,Membership早整合到Framework中，而DNN"拖拽”功能实质是中看不中用的“幌子"(只能吊吊客户的胃口),早已是明日黄花,也就是说这些技术的实现现在已是举手之劳，看看iGoogle, dropthings。不知你是否同意我的观点？说到此，不妨看看我所认识周围的DNN开发人员或项目经理是如何评价DNN的？老实说,"牛"些的哥们都不看好DNN，有的甚至在开发过程中不断唾弃DNN,指责公司乃至项目为何选择这一“垃圾”平台;有的看清其架构之后就将其摒弃于墙角；有的曾经研究过，最后抛弃了DNN。理由是各式各样的，但整理起来无非主要有以下几点（仅供参考):

1) DNN最初的框架并非是最优的(其鼻祖是IBuy Portal),而之后为了兼容性对于一些性能的提升等也只能作折中的妥协处理，故理智的对待DNN性能问题是你选择DNN首先值得参照的一点，其他可想而知。

      2) DNN是一个理想的内容管理系统,其效率足于让你瞠目结舌，但若想在其框架上开发业务比较复杂的项目，比如前边提到的电子商务，ERP等等，那你就得慎重考虑了，尽管有过成功的范例，比如最知名的CataLook电子商务套件模块就可以满足一般的电子商务需求。但风险依然存在，因为DNN一直以来存在一个"致命之症",当初引入了模块开发插件化理念，同时也引入了这一隐患，那就是DNN每个模块都是独立的，它们相互之间是不可知的，从而导致页面跳转及模块交互变得错综复杂，这也是初学者最不可理喻的，无从下手之处，如今DNN经典而常用的传参方式无非有两种方式:
     <1>URL传参，也就是利用URL将参数传递到目的页面，优点是清晰明了，缺点是安全性极低。以后我会专题介绍在DNN模块交互如何用URL方式最好最优的传递参数。(文章已添加，请参看"解除DNN的传参枷锁")
     <2>IMC传参，即是DNN默认实现的模块交互接口，鼎鼎大名的Inter Module Communication,关于如何使用IMC，官方曾有文档对此有所提及，但是不详细，我之前曾写过相关文章:

DNN特性之IMC

   以下链接也是一份详细教程，有兴趣者不妨看看:
      DotNetNuke Inter-Module Communication or: How Your Modules Can Get Their Chat On
      正是由于以上所列举之局限，在DNN中开发复杂应用须清楚其中潜在的风险，本人所碰到的项目最初选择DNN，最后抛弃DNN也有好些，当然也有些勉勉强强搭上DNN的末班车，但那也不过是无奈之举，因为此时重构或重新开发已是不可能的。

3)DNN永远是Microsoft国度的一员，这将摆脱不了它的命运，此为幸事，此为不幸也。“幸”指的是将有Microsoft这一霸主的后台支持，无疑是客户选择平台最为看重的一点。“不幸”则指它将笼罩在Microsoft的阴影下，属于自己的东西将逐渐越来越少，想想ClientAAPI为了整合兼容ASP.NET Ajax Framework就大刀阔斧的删减了不少脚本，这是优化的代价，也是失去。

好了，就此打住，下次希望能给大家更清晰的DNN架构解析以飨读者。

Baldwin's DNN

剖析DNN架构-开篇之作