将当前网站迁移到dotnetnuke

Question

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

Answer 1

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

我们坐下来与DNN，刨出我们想要的结构并建立菜单 - 1小时 然后我们打开记事本，并花了三天的时间复制和粘贴。从Live Site复制，粘贴到记事本，然后CTRL + A和CTRL + C，轻弹到DNN并再次粘贴。我的同事稍后留下的任何复杂或不合时宜的页面。三天后，我们迁移了整个网站。没有工具，没有花哨的进口和出口。

全部在几天内完成。当然，最后，我的同事也在DNN上加速。

这是一种低技术，非常成功和简单的方法。

我会考虑导入例程高度结构化的数据，但否则，我推荐这种方法。

Answer 2

你基本上需要重新创建网站，是的它会很乏味。一旦你有了一些结构，你就需要重新创建页面，假设它们是简单的内容页面。但是，如果你有一个典型的数据驱动的.NET应用程序，并且有很多服务器端代码和数据访问，那么你将不得不重新设计它，以适应DNN。无论如何，如果你想维护你现有的用户列表，你可能必须编写一个新的DNN成员资格提供者与列表进行交互。如果您已经使用了默认的ASP.NET成员资格表，这应该基本上为您完成，因为这是默认情况下DNN在内部使用的内容，尽管它将自己的成员资格提供程序包含在内，因为他们的用户必须假装是门户特定的（即使他们真的不是）。

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

如果你的代码是一堆分布在一堆页面上的spagetti，你可能需要做很多修改才能将它们放入DNN容器中。

您必须决定如何处理现有数据库。你会把它合并到DNN数据库中，还是保持它的独立性。独立的想法很好，因为它使DNN演示文稿垃圾远离核心功能，但请记住，您的用户/角色/权限也将位于DNN数据库中，因此您可能会丢失与旧数据的链接。

这导致角色和权限。 DNN使用标准的ASP.NET角色提供者接口，但并不那么简单。即使您提供自己的角色提供者来与自己的角色集成，仍然需要将角色和用户/角色分配保留到DNN表中，因为它不是完全抽象的。

......我确信一些其他特定于您的情况的东西，我想不出来。

无论如何，你可能会在中间的某个地方结束。你不会找到一些神奇的移植工具，将你的东西移植过来，但你可能不必重写每一行代码。根据网站的规模和复杂程度，您可能需要进行大量分析，并使用一些具有DNN专业知识的人员来制定稳定的计划。