将当前网站迁移到dotnetnuke

Question

将现有网站迁移到DNN是不是很繁琐？从头开始会是一个更好的主意吗？

Answer 1

去年我迁移了一个150页的网站，它并不单调乏味。

我们和DNN坐下来，规划了我们想要的结构，并建立了菜单-1小时然后我们打开记事本，花了三天的时间复制和粘贴。从Live站点复制，粘贴到记事本，然后按CTRL +A和CTRL + C，单击到DNN，然后再次粘贴。我同事留下的任何复杂或arkward页面。三天后，我们完成了整个站点的迁移。没有工具，没有花哨的导入和导出。

几天之内就搞定了。当然，在它的最后，我的同事也在DNN上加速。

这是一种低技术、高度成功和简单的方法。

对于高度结构化的数据，我会考虑导入例程，但在其他情况下，我推荐这种方法。

Answer 2

你基本上需要重新创建站点，是的，这将是单调乏味的。一旦你有了一些适当的结构，你需要重新创建页面，假设它们是简单的内容页面。

但是，如果您有一个典型的数据驱动的.NET应用程序，其中包含大量服务器端代码和数据访问，则必须重新设计大量代码以适应DNN。

无论如何，如果您想要维护现有的用户列表，您可能必须编写一个新的DNN成员提供程序来与该列表进行交互。如果您已经在使用默认ASP.NET成员资格表，这基本上应该为您完成，因为这是DNN内部默认使用的，尽管它确实用自己的成员资格提供程序接口包装了它，因为它们的用户必须假装是特定于门户的(即使他们实际上不是)。

希望你的很多代码都在用户控件和类中。如果是这样，您可能可以将它们包装在DNN容器中。这将是单调乏味的，需要大量的bug修复，但它是可行的。

如果您的代码是散布在一堆页面上的一堆spagetti，那么您可能必须进行大量更改才能将它们放入DNN容器中。

您必须决定如何处理现有的数据库。您是将其合并到DNN数据库中，还是将其单独保存。分离的想法很好，因为它使DNN表示垃圾远离您的核心功能，但请记住，您的用户/角色/权限也将在DNN数据库中，因此您可能会丢失与遗留数据的链接。

这就引出了角色和权限。DNN使用标准的ASP.NET角色提供程序接口，但它并没有那么简单。即使您提供了自己的角色提供程序来与自己的角色集成，您仍然需要将角色和用户/角色分配持久化到DNN表中，因为它没有完全抽象。

..。我敢肯定还有一堆我想不到的针对你的情况的东西。

无论如何，你可能最终会在中间的某个地方结束。您不会发现一些神奇的迁移实用程序可以直接移植您的东西，但是您可能也不需要重写每一行代码。根据您站点的规模和复杂性，您可能需要进行大量分析，使用一些具有DNN专业知识的人员来确定可靠的计划。