12

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

你对这样的模型有什么好的/坏的经历？

有什么你会警告或推荐的吗？

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

4

7 回答 7

14

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

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

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

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

于 2009-02-11T01:20:09.873 回答
6

呃，DNN？真的吗？

我在这里为火焰敞开心扉，但它是为一个不同的、不那么文明的时代而设计的产品（VB.NET，I18N 支持不佳，没有 msterpages）。现在甚至在 ASP.NET 中也有更好的框架，在 Drupal 之类的东西中也有更好的 CMS。我认为它很好地让我们度过了 ASP.NET 1.1 的痛苦，但我认为这些天你的标题问题的答案是“不”。

于 2009-02-10T12:42:37.853 回答
5

我从事过几个 DNN 项目。有几件事我似乎总是卡在上面。

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

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

最后，如果您需要一个模块来做一些特定的事情并且需要自己构建一个。如何做到这一点并不那么直观，并且在我们用于两个不同项目的 DNN 版本之间，该过程发生了变化。

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

于 2009-02-11T20:58:45.403 回答
2

我现在已经在我现在的职位上工作了 6 个月，并且几乎完全在 DNN 中进行开发。在这次演出之前，我没有 DNN 经验。所以这会让你知道我来自哪里。

好处

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

DNN 用于从 DB 中创建对象的 hydrator 模式非常巧妙且运行良好。它还迫使您使对象属性与存储过程/查询保持简洁，因此将混淆保持在最低限度。

有大量的 3rd 方模块开发人员。而且这些模块通常很便宜。所以你可以利用这些来省钱。（雪覆盖和DNN 市场）

缺点

我注意到一件事，但我们无法弄清楚原因，但 DNN 会不时丢弃它的皮肤。没有错误，也没有明显的原因。它只是不应用它们，并且在服务器重新启动之前不会这样做。

文档是残酷的。如果您要使用 DNN，请购买一本书。没有这本书很容易，但是当您需要参考资料时，找不到任何有用的资料。

于 2009-03-27T21:11:47.167 回答
1

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

一旦您了解了 Dotnetnuke 的工作原理，它就很棒。文档缺乏但越来越好。

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

于 2009-05-27T12:26:30.933 回答
0

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

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

我还没有看过Drupal。它更现代，更经常用作通用 Web 门户的基础。但我仍然对将它用作我大量定制的东西的基础持怀疑态度。

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

于 2009-02-10T17:46:19.387 回答
0

自从近 20 年前它的 beta 测试版以来，我一直在断断续续地使用它，并且可能有 10k 小时的时间投入到在 DNN 之上构建网站和 Web 应用程序上。这是我的看法...

我知道我迟到了，但对于其他考虑使用 DNN 的人，请意识到从长远来看，你很有可能会后悔。

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

但是，您应该注意 DNN 的一些主要缺点。我曾经很喜欢它。现在，我什至不会考虑将它用于新建项目。

以下是 DNN 的一些问题：

  1. DotNetNuke 不是真正的 CMS！如果不添加昂贵的第三方模块，您将无法使用它来管理内容类型。
  2. 几乎不可能调整管理 UI 以满足客户的要求或改进低于标准的创作 UX。
  3. 零创新 - DNN 在所有方面都落后于 Drupal 和 Wordpress 等其他 CMS。自从 2000 年代初期产品问世以来，他们没有对那里的产品进行任何创新
  4. DNN 团队仍然未经修饰和错误，似乎不断地重新发明轮子，为了改变它们而改变事物。
  5. 它建立在非常陈旧的技术网络表单之上，并且没有计划重振其核心。
  6. 它变得越来越商业化，而开源越来越少。您会发现在许多其他开源项目中普遍存在的社区意识并不多。

我的博客上有一篇关于 DNN 缺点的完整、更详细的文章。高温高压

于 2019-01-26T01:46:47.630 回答