我们应该在DotNetNuke平台上构建我们的下一代Web应用程序吗？

Question

我们目前正在考虑使用DotNetNuke作为我们未来基于门户和客户端可自定义的Web应用程序的基础，该应用程序将集中托管。我们的想法是将动态部分作为DNN模块，然后与后端WCF服务进行通信，后者负责业务处理和数据存储。

这种模式你有什么好/坏经历？

你会警告或推荐什么？

任何建议都将不胜感激，谢谢......

Answer 1

DotNetNuke可以成为一个强大的平台。大多数打击它的人实际上并没有将它用于任何事情，但只知道它是很久以前创建的。

我可以给你一些优点和缺点来看看。使用它比其他CMS平台的主要优点是它是一个非常成熟的平台，周围有一个非常大的社区（例如Snowcovered）。对于大多数任务，它要么已经内置，要么就已经有人建立了一个模块来完成它。它的体系结构已经构建为支持高可用性应用程序的缓存和服务器场配置，如果您正在查看大量请求，这将消除一个主要问题。

但是，DotNetNuke可能令人失望的地方是你需要在模块中执行多步骤过程。对于任何CMS来说都可能是这样，但是你会觉得你正在努力获得多个单独的模块以提供“紧密”的用户体验。我真的没有一个具体的例子 - 这只是你从经验中得到的感觉，一切都在自己的“容器”中。另一件事是开箱即用，它只是没有Web 2.0外观。你可以自定义皮肤和样式表来做任何你想做的事情，但由于某种原因，这对于整个DNN阵营来说并不是一个重要的优先事项，就像Drupal和其他人一样。

所以我想如果我必须做一个总结，我会说如果你正在寻找一个快速的方法来获得一个可定制的CMS，你对CMS平台的局限性感到满意，那就去吧它。但是，如果您的UI对您来说是最重要的，并且您愿意花费大量精力使其完全符合您的要求，那么使用ASP.NET母版页等创建您自己的应用程序。

Answer 2

是的，DNN？真？

我在这里为自己开火，但它是为不同的，不太文明的时代（VB.NET，糟糕的I18N支持，没有msterpages）而构建的产品。现在甚至在ASP.NET中本地存在更好的框架，在Drupal这样的东西中也有更好的CMS。我认为让我们度过ASP.NET 1.1的痛苦是相当不错的，但我认为这些天你的标题问题的答案是“不”。

Answer 3

我参与了几个DNN项目。有一些事情我似乎总是被困住。

首先，也许最重要的是菜单。内置的菜单和购买的菜单模块都非常有限且难以使用。我们使用xml转换来呈现为菜单创建html。但是，我们返回给我们的xml是一个扁平的xml文件。意思是不使用层次结构，这限制了一些你可以做的子菜单。所以0级到4级菜单项都是彼此的兄弟姐妹。

其次，有许多模块可供选择。如果标准DNN没有做某事，则很可能是一个模块。但是，这些模块的质量因模块而异。

最后，如果您需要一个模块来执行特定的操作，并且需要自己构建一个模块。关于如何做到这一点并不直观，而且我们用于两个不同项目的DNN版本之间的流程也发生了变化。

我想说如果你愿意真正学习DNN，它可能是一个非常有用的工具。但如果这是一个一次性的项目，我认为最好不要管它。

Answer 4

我现在已经工作了6个月，几乎只在DNN开发。在这次演出之前，我没有DNN经验。所以这会让你知道我来自哪里。

优点

DNN真的很容易学习。管理界面非常直观，代码库非常一致。我很少需要在我的桌面上参考DNN书籍（通常只是为了深奥的细节。）

DNN用于从DB创建对象的水合器模式非常灵活且运行良好。它还会强制您使用sprocs / query保持对象属性的简洁性，从而将混淆保持在最低限度。

有大量的第三方模块开发人员。这些模块通常很便宜。所以你可以利用这些来省钱。 （SnowCovered＆amp; DNN Market Place）

缺点

我注意到了一件事，我们无法弄清楚原因，但DNN会不时地放下它的皮肤。没有错误或明显的原因。它只是不应用它们，在服务器重启之前不会这样做。

文件是残酷的。如果您打算使用DNN，请阅读相关书籍。没有这本书就很容易了，但是当你需要参考资料时，找到 NONE 是非常有用的。

Answer 5

我参与了各种dotnetnuke项目，从简单的博客扩展到成熟的网站创建者（创建自定义子门户）。

一旦你了解它是如何工作的，Dotnetnuke就很棒。文档缺乏但越来越好。

我对dotnetnuke的抱怨是难以进行单元测试。

Answer 6

我没有使用Dot Net Nuke的经验，但我查看了源代码，并考虑使用许多“内容管理系统”作为Web应用程序的基础。

这种方法的问题在于，这样的系统几乎总是有一个架构，使得完全你想要的东西非常痛苦。商业类库设计主要是为了重复使用（由专业公司），他们可以解决他们的问题。内容管理系统甚至没有设计以重复使用其代码，即使人们有时会尝试这样做。很容易找到一个看似简单的元素（作为一个组成的例子，比如一个显示文件数量的字符串），并以非常令人惊讶的方式放在页面上。这使得修改或删除简单元素变得困难 - 如果您可以找到元素如何放在页面上的话！还要记住，对于这些应用程序，您还在某种程度上依赖于集合的更新和错误修复。呃，也因为这些事情很常见，他们更容易受到共同利用（如phpBB often is）。

我没有看过Drupal。它更现代，更常用作通用门户网站的基础。但我仍然怀疑使用它作为我大量定制的东西的基础。

除非您希望不对初始DNN架构进行大量修改，否则我会回避您的建议。

Answer 7

自从大约20年前的beta版以来，我一直在使用它，无论我是在使用中还是关闭它，大概有10,000个小时的时间用于在DNN之上构建网站和Web应用程序。这是我的...

我知道我参加晚会很晚，但是对于任何考虑使用DNN的人，请意识到，从长远来看，您很有可能会后悔。

要回答OP的直接问题，当且仅当您构建的模块不需要与DNN核心交互并且以内容管理为中心时，这并不是构建OP的糟糕解决方案。对于基本的客户门户网站来说，可能还可以，您希望用户能够登录，访问某些信息或资产等。

不过，您应该注意DNN的一些主要缺点。我曾经喜欢它。如今，我什至不会考虑将其用于未开发的项目。

以下是DNN的一些问题：

1. DotNetNuke不是真正的CMS！您必须先添加昂贵的第三方模块，才能使用它管理内容类型。
2. 几乎不可能调整管理UI来满足客户的要求或改进以下标准的创作UX。
3. 零创新-DNN在所有方面都比其他CMS（如Drupal和Wordpress）落后数年。自2000年代问世以来，他们就一直没有对该产品进行任何创新
4. 它仍然没有打磨和越野车，DNN团队似乎不断地重新发明轮子，为了改变它们而改变了事物。
5. 它是基于非常过时的技术网络表单构建的，并且没有振兴其核心的计划。
6. 它变得越来越商业化，越来越少的开源。在许多其他开放源代码项目中，您不会发现普遍的社区意识。

我的博客上有完整的more detailed writeup on the drawbacks of DNN here。 HTH