如何看待DNN(DotNetNuke)的模式,是否适用于企业应用开发

[codeprince]

表象上DNN(DotNetNuke)是一个配置内容管理的代表之作,可是对于一个面向企业开发的应用程序,尤其是当模块之间的跳转(或者说是模块之间的联系)相对紧密时,DNN的设计不只能否适应,我想将下一个项目移值到这个平台上但是有几点不是很清楚:
1.架构的兼容性(是否使用VS2005.)
DNN的内核是基于1.1框架,而在VS2005对ASP.net做了不少的改动,尤其是架构,所以如果使用原有的DNN(3.010或3.07)将出现不兼容的情况;另一方面,就是对DNN进行改动,以适应VSS2005的需要,但是工作量好象不如抛弃DNN自己构架.

2.DataProvider的适用性(不用StoreProcedure)
DNN中的DLL是很有特点的,DataProvider就具有代表性,但是基于StoreProcedure的模板式开发对于一些数据库(如mysql,DB2...)对存储过程支持相对不是很好的,那么这套模板似乎诱惑力并不是很大,尤其我现在使用IBMDB2,好象觉得使用存储过程并不如使用CommandText好,但是我也在考虑DataProvider的扩展性,这也是一个让我很费神的地方.

3. 模块的跳转
和几个同事讨论了一下,大家对DNN在复杂流程的控制方面持怀疑态度,经管我强烈支持,对于页面之间的传递(使用TabID,MoudleId,Ctl..)应该不会有什么问题,但是毕竟没有做模块之间的跳转测试,也不能确定是否控制起来有难度.

[回回keke]

我做过开发的演讲,发现里面的模块开发特别麻烦,没有好的调试方法,

[menuvb]

曾经对DNN2.12有过比较久的研究。可以看我以前写过一些心得

http://www.cnblogs.com/zc_net/category/6147.html

如果对DNN有过深入了解。发现它的原理实际上也是比较简单，整个网站实际上就是有一系列的模块构成，不过DNN2.12就研究的时间少去了。
已经准备开始研究DNN3.0.12了。到时交流交流。
国内企业使用DNN的还是比较少，因为它按现在模型很难符合国内各个企业的应用。除非对它进行比较大的修改，当然它的架构确是一流的。我现在的应用和架构就是有许多采用了DNN的方式，比如你所所说的工厂模式DataProvider

[HONGDUN]

最近也正在研究。愿意与大家一起交流。

[whidy]

看了以下介绍,不知可以用来做什么.只是对其皮肤功能感兴趣

[Bob]

还没有研究过DDN,看来要研究研究了!

[youngby]

^_^~~

i copy the code fro DNN ,,,,

[fufucn]

微软的东西向来是以用户都使用微软产品为前提的，默认就认为你使用的是sql server

[cat_hsfz]

如果要求ASP.NET 2.0的话，Sharepoint v3（可能会命名为Sharepoint 2005吧）应该会适合，不过就是不知道什么时候才能用到。

[niunj]

哪边有这个方面的资料共研究啊?

[microhf]

那位靓仔好心给我发一份！
[e-mail]
我一早晨了还没等到Verification Code
多谢！

[zlc810821]

那个东西，能够提供很多新鲜的思路。
不过如果想做一个高性能的网站，是不可能的。主要访问的页面都是default.aspx 。
还有在新闻方面支持的不好。
如果做一个简单的介绍性网站还不错。

[hihin]

那个东东是学习用的，不是拿过来就可以作为企业应用赚钱的

[codeprince]

menuvb(戏子……) :这几天因为手里的一个项目太忙了,不过还是抽空看了你的Blog,分析的不错,有个感觉,因为是随笔,"树木"多了一些,如果能够对整体有个详细的分析,可能会更好一些,国内有一些对DNN做研究的,看了之后,都不如自己阅读DNN Doc,对于DNN的应用价值,我现在也是持保守态度,给我的感觉,它是一个非常好的进一步学习.net的素材,对于规范化软件开发,有很大的价值.
非常感谢各位的回复!

[wwh207]

gz

[hjf1223]

我下过一个DNN源码，可是是VB代码。看不习惯，有没有C#版的啊？现在去找找

[以专业开发人员为伍]

没用过那个东西，也没有研究过代码，但是似乎问题还是很好回答的。

1. “是否适用于企业应用开发”这个问题只能得到似是而非结论。因为内容管理是菜单、皮肤、模版等概念的集成和发展，是个RAD工具。工具是否适合在工厂里使用，这没有定论，全看你想做什么、客户有多少。

2. 2005年版的开发工具通常应该在2007年才全面使用，不是么？

3. 存储过程的目的是封装一些复杂的逻辑，如果你的存储过程全都是用来封装一两句SQL查询，并且没有复杂的动态参数集合需要处理的时候，当然无所谓用存储过程还是CommandText，此时只不过后者对于系统开发和维护者而言没有复用、改进时必须逐一改变。这对于要求较快开发的人是不能接受的。快速开发的人往往要花大把时间研究风格、方法，尽量复用。这也不过是个人习惯。只有非常快之后，那么那些经验就发生了质变，就变成了一种编程癖好。这就好像庖丁喜欢研究牛的生理结构，但是当他用此方法杀鸡的时候你就会觉得他很多余。

4. 我没有看过DNN，但是内容管理我还是比较了解。内容管理的根本架构，简单来说就是“一个”页面通过接受“内容ID”然后（通过借助数据库）来解释性地决定显示的内容。所有的文字、图片、导航等都是这个因这个ID的动态改变而动态决定出来的，而不是与页面相关的。不需要这种机制就没必要操心性能问题，就好像不需要.net就没必要操心多层次的转译和编译对系统效率的降低。近十年软件界几乎所有令人“激动”的变革都曾经被人担心为“效率很低”，这很平常了。我建议更关心“机制”问题，先了解，把“效率”评价放在其次。

[以专业开发人员为伍]

这里有一个小程序，从分析用户需求到设计到这个演示程序的样子共用时两个月，如果扣除研究一些纯技术问题的事件大概用时1个月完成。好几个地方仰赖于“工具式”的架构而不是一个一个页面去写。

http://cmda618.vicp.net/W2CMs/

用户名: wuwei
密码: 123456

[以专业开发人员为伍]

刚刚开始内部测试，请仅浏览不要修改数据。

这个程序完全是用vb.net写的，除了TreeView之外没有使用任何vs.net2003基本内容之外的组件，而是自己写的组件。自己写的好处就是扩展性有保证。

[fzxml]

mark

[Truly]

我喜欢他的架构模式