我将是第一个承认这篇博文应该在几周前就写完的人，然而，在我能给这篇文章一个公正的评价之前，有很多事情需要解决。在深度神经网络技术咨询小组(TAG)内部，深度神经网络与。net Core相关的未来已经被详细讨论过多次。在过去，这些对话已经得出了多个结论，然而，在最近的讨论中，由于微软的一些明确表态，一项短期决定已经到位。在这篇文章中，我希望尝试分享这些讨论的亮点，决定背后的原因和未来的道路，最终就像现在一样，DNN。
net核心?是什么，为什么?
这篇文章不是要解释什么是。net Core，或者你为什么要关心它。然而，重要的是至少要对为什么这是DNN平台的关键决策点有一个基本的了解。三年前，几乎就在同一天，微软发布了一个名为。net Core的新产品。net Core是跨平台的，开源的，与目前的ASP完全不同。. NET技术栈。
在过去的三年里，我们见证了。net Core学会了如何爬行、走路、跑步、开车以及去上大学。与。net框架相比，它的变化速度是前所未有的。主要的功能添加、升级、突破性的变化、支持上的困惑，以及微软在方向上的不明确。随着。net Core 3.0在未来的某个时候发布，微软终于开始制定一些基本规则，以帮助制定未来的路线。
我最近刚刚写了一篇博客.NET Core / .NET Framework我对未来的看法这就更深入地探讨了这一切的定位。我建议，在继续这篇文章之前，如果你有时间，先读一下这篇文章。
深度神经网络的未来:社区投入
在我进入。net Core和DNN的细节之前，我认为有必要看看DNN的未来，以及TAG小组为社区“重要”的项目征求的反馈。正是这些反馈在决定DNN平台的未来方向方面起到了至关重要的作用，至少在短期内是如此，因为最终，如果没有围绕着它的积极参与的生态系统，DNN就不会存在。
可升级性或长期支持当前
尽管不是普遍的，但对于开发人员来说，需要一些可用的迁移过程几乎是普遍的。如果没有升级路径，那么需要在现有平台上为存在于DNN生态系统中的那些平台制定一个真正的长期计划。
对，错，或无所谓我们有数亿美元的扩展建立在DNN平台上。这些扩展中的大多数都是在WebForms开发模型上开发的，因为它已经存在了很长时间。每个人都明白这个平台需要成长，但关键是我们不能消灭已经存在的社区，我们需要他们继续前进。
管理经验(个人栏)需要修正
在讨论当前的需求时，大家一致认为PersonaBar需要改进，以解决以下问题:缺少功能、bug、缺乏可访问性、缺乏移动支持等等。每个人都知道，任何过渡到。net Core，或其他方式，都需要时间，努力确保PersonaBar的功能，并确保我们有一个稳定、可用的解决方案，这对于在任何过渡发生时保持现有客户的满意是至关重要的。
性能与稳定性
下一个最受社区关注的问题是DNN平台的性能和稳定性。多年来，DNN平台的规模已经大大增长，随着这种增长，有些领域的性能已经下降，或者引入了一些不稳定因素。按钮点击不起作用，或者性能问题还没有解决。在具有大量门户、用户、页面或大量流量的安装中，这些问题通常会被夸大。
能够一致地处理客户负载被列为一个关键因素。
文档
最后一个关键的讨论点是关于文档，我们有一个了不起的平台，然而，文档严重缺乏。由于缺乏标准文档和资源，这使得许多事情难以完成。在组成DNN平台的15年的开发过程中，我们拥有了分散的API模型，这使得发现操作经常成为一种捉迷藏的练习，而不是简单的发现。这增加了新用户进入该平台的门槛。
为什么。net核心对DNN来说很复杂?
在迁移到。net Core时，与其他平台和项目进行了很多比较。正如我在另一篇博客中提到的，每个项目都有不同的处理方式。对于DNN，我们有一些关键的东西，使我们的生活在前进的过程中变得有趣。
严重依赖WebForms
许多ASP。.NET的特性已经延续到。NET Core世界，然而，DNN和许多模块所基于的WebForms开发模型在。NET Core中没有得到支持。微软也没有任何支持这种模式的计划。这是DNN平台在两个方面面临的最大障碍。
首先，这是一个巨大的障碍，因为整个DNN平台是基于WebForms模式的。每个页面的构建、主题的加载、模块的放置、缓存、URL重写等都是使用WebForms管道来实现的。当然，DNN有一个实现，允许开发人员在他们的模块中使用“MVC”。但是，这个实现是通过简单地将MVC“添加”到WebForms管道中来完成的。改变这一点是一项艰巨的任务，需要重写使DNN成为今天的大部分内容。
其次是对社区中其他人的影响。我们没有一个可靠的过渡计划，一旦我们从DNN中删除了WebForms，所有依赖于WebForms的扩展，其中一些甚至在2018年也不能以不同的方式完成，将不再工作。这是一个不需要100%解决的问题，但对当前用户的未来支持至少是一个优先事项。
一个不支持。net核心的数据提供程序
此外，在幕后，DNN利用一个名为PetaPoco的组件来执行许多数据库操作。这通常被称为DNN名称DAL2。这个库目前还不支持在。net Core上运行，随着PetaPoco项目的上线，最近似乎有一些支持。net Core的活动，然而，进展还没有那么远。
理想情况下，新版本的深度神经网络将使用更标准的数据访问解决方案。我的偏好是使用EntityFramework Core来跟随。net Core世界。这是可行的，但它需要重写系统中的每一个数据库调用。这是需要调整的数十万行代码。
不支持当前标准的API模型
迁移到。net代码的另一个考虑是遵守当前的编码标准和最佳实践。. net Core的主要卖点之一是对依赖注入的原生支持、可组合性以及轻松测试实现的能力。DNN平台API在当前状态下没有遵循任何一致的结构，对依赖注入的支持非常有限，并且整个平台不支持下游用户的这些概念。
如果我们想要吸引新的开发人员受众，那些关注。net Core的人，那么DNN尽可能地遵循设计模式将是非常重要的。准入门槛越低越好。用。net Core的方式开发要比用DNN。net Core的方式容易得多!但要做到这一点，需要进行重大重构。
迁移的成本是什么?
迁移的成本究竟是多少，以开发人员的工作时间或其他可量化的成本来衡量。这个问题已经得到了很多讨论，目前的决定是，我们不能轻易地给出一个可靠的数字，直到我们确定我们可以在破坏变化等方面做出多少妥协。
不管我们如何划分，我认为最好的情况是，我们将看到一个超过8000 - 9000小时的迁移过程，包括质量保证时间，以确保功能能够正常工作。有很多未知因素，所以这个数字可能被严重低估了。我自己已经完成了许多从WebForms - b> . net Core的迁移，我非常有信心它不会被高估。
最后，在社区的推动下，在一个完美的世界里，这将是一件需要数年才能完成的事情。
隐性成本
我认为值得注意的是，一旦平台过渡到。net Core，也会有隐藏的成本。. net Core的支持模型与。net Framework的支持模型有很大的不同。最好的支持周期是3年，如果我们要在微软发布。net Core的同一天管理DNN的发布，我们的社区就需要把注意力转移到网站的升级和管理上。
对也好，错也罢，我们有成千上万的网站，它们的DNN版本已经有2年、3年、5年、10年的历史了，包括一些早期的DNN 1.0网站，它们至今仍在使用。在一个安全支持仅在短短三年之后就结束的平台上，这种做法是不可能继续下去的。
作为一个开发社区，这也会稍微增加项目的持续管理，因为我们必须确保整个平台保持最新状态。
我们必须移民吗
这是一个最近才变得更加清晰的问题。简短的回答是一个简单的NO，我们不需要迁移。net框架，包括我在另一篇文章中提到的WebForms，至少到2027年才会被支持，我们还有时间。
然而，如果我们不开始一个行动计划来前进，我们将是疏忽的。真正的未来是。net Core，这是不祥之兆。但我们如何达到目标比我们达到目标这一事实更重要。没有社区的。net Core DNN只不过是另一个没有支持的开源产品。
TAG小组的决定
综上所述，了解DNN TAG小组决定做什么是很重要的。鉴于上述所有情况，我们需要共同努力，帮助改进DNN平台，使我们朝着人人共享的未来迈进。近期目标已确定如下。
- 修复PersonaBar!这是9.3中包含的大量工作的第一优先级，主要关注9.4版本。修复问题、添加缺失的功能、提高性能和PersonaBar的可访问性都在日程表上。
- 提高现有代码库的质量。已经实现了多轮优化，但是还有很多工作要完成。这项工作是为了遵循编码最佳实践，并使代码达到一定程度的一致性，以便在我们进行转换时更容易重构api。
- 开始构建一个支持。net核心概念的新API模式，包括依赖注入。我们有能力编写使用相同原则的。net框架代码，重组当前的API将是推动内容向前发展的良好开端。
- 努力使尽可能多的项目符合DNN平台。net标准。通过使子项目。net Core兼容，这将使我们更好地了解哪些代码可以在。net Core上工作，哪些不能。这对于保持未来的记分卡至关重要。
- 在可行的情况下，尽快将项目向前推进，删除旧的未使用的方法。一个官方弃用流程在6月份创建，这一过程将遵循，但将允许一个明确的时间表来清理API
除了这些优先级之外，我们将继续关注微软在。net Core方面的进展。如果情况发生变化，允许更激进的时间表，该集团将重新考虑。我们会做到的，但关键是要有一个伟大的产品，我们的社区尽可能完整。
总之
我希望这篇文章能够为过去5个月里发生的所有讨论和活动奠定基础。对于那些想要更多地参与技术咨询小组会议的人，我可以很高兴地将这些会议的信息转发给任何想要参加的人。
作为小组的领导，我将努力把这样的信息传达给那些无法参加这些会议的社区。每次会议后一周，会议议程也可在社区博客．
这篇文章是交叉张贴到我的个人博客。