时间戳

首页 > 解决方案 > 将 EF Core 与 ASP.NET Core MVC 和 Sqlite 一起使用 - 正确的类结构

c# - 将 EF Core 与 ASP.NET Core MVC 和 Sqlite 一起使用 - 正确的类结构

问题描述

我对编程比较陌生，我有一些问题。我目前正在同时尝试从 Microsoft 官方书籍中学习 ASP.NET MVC，因为我希望在几个月内获得认证，同时为同事开展一个小项目。我没有使用 .net 框架做事，而是决定只在 .net core 中做所有事情，我在书中学到的内容与 EF Core 中似乎可用的内容之间存在一些差异。

我正在将 Sqlite 用于我的数据库，并且我已经将其大部分插入，但我遇到了一些问题，互联网上的各种人向我提供相互冲突的信息。

所以在 ASP.NET 的 .net 框架版本中，微软说你应该做的事情是，你有一个模型PersonModel和一个上下文PersonContext，它进入模型文件并继承DbContext. 这PersonContext包含各种DbSet<T>对象，具体取决于您要制作的表格等。这对我来说在 .net 核心中保持不变。但是，在此之后，Microsoft 告诉我创建一个PersonInitializer应该继承DropCreateDatabaseAlways<PersonContext>然后覆盖 Seed 方法的方法（方便地，这也是getFileBytes为图像放置方法等的地方）。

现在，在核心中，没有要继承的 DropCreateDatabaseAlways 类，这让我相信这个结构实际上根本不是 .net 核心想要的。我在这里听说过关于使用各种 CLI 命令的各种事情，但最后我基本上只是对“正确”的事情在这里做什么感到非常困惑？

标签： c#entity-frameworksqliteasp.net-core.net-core

解决方案

它认为您目前最大的问题只是正确地获取信息。诚然，这有点令人困惑，尤其是对于一个全新的人来说。

开始的一些背景知识：有 ASP.NET、ASP.NET MVC 和 ASP.NET Core。ASP.NET 实际上什么都不是，尽管它成为 ASP.NET Web 窗体的简写，因为那是您当时唯一必须使用的东西。然后，微软推出了 ASP.NET MVC，它在 ASP.NET 的基础上，尝试以 MVC（模型-视图-控制器）模式为模型的现代 Web 应用程序框架。这是对 Web 表单的巨大改进，但并没有从根本上脱离旧系统，足以使其成为真正出色的应用程序开发框架。由于它依赖于System.Web（一个单一的 DLL 家族）和完整的 .NET 框架，因此速度慢、难以部署并且与容器化等完全不兼容。进入 ASP.NET Core，这是从头开始的完全重写。

ASP.NET MVC 在 ASP.NET Web Api 中有一个姊妹框架，从技术上讲，您仍然可以在同一个项目中使用 ASP.NET Web 窗体。事实上，一个项目可以同时使用所有三个框架，这听起来很复杂。至少在最初，ASP.NET Core 消除了这种混乱，只为传统的 Web 应用程序和 API 提供了一个系统。因此，如果您正在寻找有关 Core 的信息，它只是“Core”。寻找 ASP.NET Core MVC 只会将您引向过时的信息。

话虽如此，令人沮丧的是，微软以他们无限的智慧决定使用 Web 表单，尽管大多数曾经使用过真正Web 应用程序框架，实际上太棒了，它们应该复活，至少在精神上。因此诞生了 Razor Pages，从那时起就有必要区分 ASP.NET Core Razor Pages 和 ASP.NET Core Proper，后者现在已重新标记为 ASP.NET Core MVC，这对人们来说变得更加困难过滤掉一个框架与另一个框架的信息。至少目前，Razor Pages 仍然没有 MVC 风格那么突出，幸运的是，它们至少在 Core 的核心功能上没有太大变化，以保证对大多数事情进行不同的讨论。总而言之，您几乎应该只为每个搜索添加前缀"asp.net core"（在引号中，因此它是作为短语搜索完成的）。这通常总是会为您提供相关信息 - 在大多数情况下。

下一组问题是 ASP.NET Core 的开发具有很高的可见性，完全公开，并且有许多预览、alpha、beta 甚至完整版本。一方面，这很棒，这也是它如此出色的很大一部分原因。开发人员能够提供输入并指导开发，使其成为 Microsoft 开发的第一个 Web 应用程序框架，实际由实际在战壕中的人们设计并为他们构建 Web 应用程序。

然而，不利的一面是，事情发生了很大变化，而且仍然如此。不过，它现在似乎在 2.1 之后趋于平稳，我认为这几乎是第一个真正功能完整的版本。然而，在我们来到这里之前，我们有 ASP.NET vNext、ASP.NET MVC 6、DNX，然后是 ASP.NET Core 1.0、1.1、2.0，最后是 2.1——所有这些都从根本上改变了至少某些事情的工作方式。换句话说，即使您将搜索限制在 ASP.NET Core，仍然有那里有很多过时和不正确的信息，仅仅是因为它是关于以前的版本而写的，从那以后情况发生了变化。为了提高您的胜算，您应该考虑将搜索范围限制在去年（2018 年以上，2017 年，如果您找不到任何更新的内容）内发布的内容。任何比这更早的，你将不得不带着一大粒盐来接受这篇文章。

然后这将我们带到了实体框架。天啊。英孚有一段传奇的历史，其中大部分都沉浸在失败中。最初的 EF 直到版本 3 才可行。以前的版本非常糟糕，以至于无法用于任何严肃的生产工作。即便如此，直到 EF 4 才真正被认为是真正为黄金时段做好了准备，并因此最终开始在开发人员中获得一些重要的吸收。这也是最终引入 Code First 的版本（技术上在 4.1 中）。

在此之前，EF 团队称之为数据库优先或模型优先。唯一有意义的区别是，一个可以从现有数据库生成模型，而另一个可以让您设计模型，然后从中生成数据库。无论哪种情况，您最终都会遇到一个名为 EDMX 的怪物，这是一个试图跟上您的数据库状态以及 VB/C# 类的所有转换所需的 XML 野兽。维持这绝对是一场噩梦，几乎从来没有正常工作过，而且总是令人沮丧。

Code First 提供了另一种选择——在 EDMX 地狱的黑暗深坑中闪耀光芒。您可以使用 POCO（普通的旧类对象），EF 将能够从您对这些更改所做的更改生成迁移，以相应地更新您的数据库。它甚至可以用于与现有数据库一起工作，尽管它的名字阻止了它在该领域被尽可能多地使用（许多人错误地认为，如果你有一个现有的数据库，你必须继续使用旧的可怕数据库优先方法）。事实上，Code First 是管理新数据库和现有数据库的完全替代方法。EF 5 和 EF 6 继续改进这种新方法，到了开发 EF 7 的时候，微软认为是时候让 EDMX 走向它当之无愧的坟墓了。

然而，EF 7 的开发恰逢 ASP.NET Core 的开发，后者本身衍生出 .NET Core 并最终衍生出 .NET Standard。EF 牢牢地植根于完整的 .NET 框架，因此很明显需要进行重写。因此，EF 7 的开发被取消，EF Core 诞生了。然而，EF Core 却经历了一段艰难的历程。ASP.NET Core 像货运列车一样前进，但没有与数据库交互的本地方式。您可以使用旧的 EF，但随后您被迫针对完整的 .NET Framework，而不是 .NET Core。于是，EF Core 急于发布方式太快了，1.0 是史诗般的火车残骸。缺少很多基本功能，变通方法也很迟钝，以至于几乎没有一个头脑正常的人会用它来生产任何东西。然后，1.1 发布了，情况有所改善，但还不够。然后是 2.0，最后，它是可行的 ORM，你可以在生产环境中使用它。2.1 的发布带来了更多的改进和改进。

既然您已经上过历史课，我只能说，不幸的是，找到好的文档仍然是个废话。您需要非常具体地进行搜索，使用正确的术语（这也是我想为您提供历史记录的部分原因）。您还需要密切注意日期。考虑怀疑 2017 年之前存在的任何东西，甚至用一粒盐对待那一年的东西。官方文档是你最好的朋友。微软实际上在他们的文档方面做得非常出色，并使其保持最新和准确。它涵盖了最大的大部分事物，是真理的最终来源。

书在这里不会成为你的朋友。发布过程花费的时间太长，而且 ASP.NET Core 的速度也太快了。任何关于 Core 的书在它上街的那一刻就已经过时了。但是，如果您订阅了 Safari Books，您可能会因为那里的预发布和 alpha 产品而走运。你必须处理更多的技术错误、语法错误等，但至少信息会更接近实际真相。

Pluralsight 有一些真正优秀的视频可以帮助你。不幸的是，视频制作与书籍出版有类似的问题，而且现在有很多课程已经过时以至于没有用了。

希望这至少可以为您提供更好的背景信息，并有助于提高您获取优质和准确信息的能力。老实说，我仍然为此苦苦挣扎了很多次，而且我认为在这个领域工作的大多数开发人员都有同样的问题。它既有趣又令人兴奋，但也不是没有缺点。必须在信息的海洋中跋涉才能找到一些珍珠就是其中之一。祝你好运。

推荐阅读