我们目前正在考虑使用DotNetNuke作为我们未来基于门户和客户端可自定义的Web应用程序的基础,该应用程序将集中托管.我们的想法是将动态部分作为DNN模块,然后与后端WCF服务进行通信,后者负责业务处理和数据存储.
这种模式你有什么好/坏经历?
你会警告或推荐什么?
任何建议将不胜感激,谢谢......
DotNetNuke可以成为一个强大的平台.大多数打击它的人实际上并没有将它用于任何事情,但只知道它是很久以前创造的.
我可以给你一些优点和缺点来看看.使用它比其他CMS平台的主要优点是它是一个非常成熟的平台,周围有一个非常大的社区(例如Snowcovered).对于大多数任务来说,它已经内置,或者已经有人在那里构建了一个模块来完成它.它的体系结构已经构建为支持高可用性应用程序的缓存和服务器场配置,如果您正在查看大量请求,这将消除一个主要问题.
但是,DotNetNuke可能会让您失望的地方是您需要在模块中执行多步骤过程.对于任何CMS来说都可能是这样,但是你会感觉自己正在努力获得多个单独的模块来提供"紧密"的用户体验.我真的没有一个具体的例子 - 这只是你从经验中得到的感觉,一切都在自己的"容器"中.另一件事是开箱即用,它只是没有Web 2.0外观.你可以自定义皮肤和样式表来做你想做的任何事情,但由于某些原因,这对于整个DNN阵营来说并不是一个重要的优先事项,就像Drupal和其他人一样.
所以我想如果我必须做一个总结,我想说如果你正在寻找一种快速的方法来获得可定制的CMS,并且你对CMS平台的局限性感到满意,那么就去做吧.但是,如果您的UI对您来说是最重要的,并且您愿意花费大量精力使其完全符合您的要求,那么使用ASP.NET母版页等创建您自己的应用程序.
eee,DNN?真?
我在这里打开自己的火焰,但它是为不同的,不太文明的时代(VB.NET,糟糕的I18N支持,没有msterpages)而构建的产品.现在,ASP.NET中甚至存在更好的框架,而Drupal等更好的CMS也存在.我认为让我们了解ASP.NET 1.1的痛苦非常好,但我认为这些天你的标题问题的答案是"不".
我参与了几个DNN项目.有一些事情我似乎总是被困住.
第一件事,也许最重要的是菜单.内置的菜单和购买的菜单模块都非常有限且难以使用.我们使用xml转换来呈现为菜单创建html.但是,我们返回给我们的xml是一个扁平的xml文件.意思是不使用层次结构,这限制了一些你可以做的子菜单.所以0级到4级菜单项都是彼此的兄弟姐妹.
其次,有许多模块可供选择.如果标准DNN没有做某事,则很可能是一个模块.但是,这些模块的质量因模块而异.
最后,如果您需要一个模块来执行特定的操作,并且需要自己构建一个模块.关于如何做到这一点并不直观,并且我们用于两个不同项目的DNN版本之间的过程也发生了变化.
我想说如果你愿意真正学习DNN,它可能是一个非常有用的工具.但如果这是一个一次性项目,我认为最好不要管它.