2

我过去用 php 开发过网站，现在我已经开始学习 ASP.NET MVC，因为我发现自己为桌面应用程序编写了很多 c#。

我遇到的问题是我习惯于通过函数和自定义 SQL 命令建立与 SQL 服务器的连接。据我了解，您不应该对 MVC 做同样的事情，而是使用实体框架（DbContext）在数据库和模型之间同步数据。也许我没有完全理解这背后的逻辑，但我觉得这是一种资源浪费。

我正在开发的当前应用程序需要许多与书呆子晚餐应用程序（我目前正在研究代码）相同的功能，并且具有更多的搜索功能。

有人可以让我更好地理解为什么我应该使用实体框架吗？

谢谢

4

3 回答 3

3

ASP.NET MVC 完全独立于任何类型的数据库访问；你可以选择你想使用的任何东西。但是，很多教程将使用 Entity Framework，主要是因为它是新的并且易于使用。

Entity Framework 通过将 SQL 表映射到标准 C# 类，在一定程度上简化了数据访问。如果您使用 EF Code-First，您甚至可以通过在 C# 中定义这些类来实现，并让 Entity Framework 设置您的数据库，这样您就无需接触 SQL。然后，因为您的数据库和其中的表被映射为 C# 类，您可以从 C# 代码中添加、查询、更新和删除数据库中的条目。主要好处是：

  • 您所有的逻辑都在一个地方，用一种语言。这包括定义您的类型/表、查询、插入和更新，一切。这使得编写更容易，更容易调试，并且更容易将其全部保存在源代码控制中。
  • 您的数据库实体是“普通的旧 CLR 对象”（POCO）。这意味着你可以将它们放在 a 中List<T>，你可以给它们构造函数来进行自定义初始化，你可以使用继承来简化它们的结构，澄清它们的关系并利用代码中的多态性......你可以做任何你可以做的事情一个常规的 C# 类，不需要映射或转换。

  • 您可以使用 C# 查询语法，如下所示： 

    from x in table1
where x.foo == bar
select x.thing

    或像这样：

    db.table1.x.Where(x => x.foo == bar).Select(x => x.thing);

    两者都为您提供编译时类型检查和 IntelliSense 自动完成功能，并且都将生成等效的 SQL，并且仅在您执行需要获得实际结果的操作时将查询发送到数据库，例如.ToList().

  • Entity Framework 的DbContext类就像数据库的快照，当您调用.SaveChanges()它时将任何更改应用回数据库。这使得使用事务访问和工作单元模式变得很容易，这基本上意味着如果在操作中出现问题，您可以丢弃整个更改集并知道您的数据库没有被完成了一半的任务。

有一些缺点，主要与拍摄快照并保持同步的性能损失有关，以及将 C# 转换为 SQL 的开销（有时它会占用比您需要更多的内存并在那里执行操作，但这可以通常可以通过编写良好的查询来避免），但在许多情况下，除非您的数据库很大，否则您不会注意到差异。对于刚接触 ASP.NET MVC 的人，我肯定会推荐 Entity Framework 进行数据库访问；它将消除麻烦，让您专注于逻辑。

于 2013-07-01T10:05:27.707 回答
1

你理解错了。MVC 没有任何数据库支持。你可以使用任何你想要的数据库技术，而 MVC 对此无话可说。

是的，大多数示例和演示确实使用实体框架，但那是因为 EF 使得在几秒钟内完成数据库访问变得微不足道，而无需编写一堆样板代码。ORM 用于将关系数据库映射到对象，以更好地匹配对象模型的数据模型。

如果您愿意，您可以自由使用烟雾信号和信鸽。不过，完成您的应用程序可能需要 10 倍的时间。

于 2013-07-01T09:54:11.033 回答
0

好吧，我认为您将要比较两种方法，即 ORM（实体框架）和普通 sql 对象（Sql 命令）。你应该看看这些答案。我希望你能澄清你的问题。

于 2013-07-01T07:00:07.150 回答