什么时候应该使用实体框架？

Question

我是Entity Framework的新手，当然，我在SOF上发现了很少有关目标用例的问题。

让我给你一些信息。我不是在与不同的数据库供应商或不同的数据库打交道;只有一个，SQL Server 2008和数据库少于30个表。我是否真的需要重做事物并使用实体框架？

编辑：

感谢詹姆斯解决我的问题。所以我假设使用EF会增加开销并在背景中做一些我不知道的工作。这是MS的工作方式，所以我猜我的下一个问题是：

1. 它是否也会影响效果？

2. 它是否支持hierarchyid数据类型？

Answer 1

使用实体框架（或任何其他Object-Relational-Mapper，如LINQ to SQL，NHIbernate等）的主要原因是为了在您的应用程序中更轻松地访问数据。使用EF，您只需将新值分配给.NET对象，即可通过LINQ查询和简单更新，而无需自己编写任何SQL代码。

我个人使用EF Code First和EF Migrations进行绿色领域开发，使用LINQ to SQL进行构建的现有数据库。

Answer 2

<强>及其 最重要的功能如下：

• 默认情况下，它会自动从模型中生成类 在模型更改时动态更新这些类。

• 它负责所有数据库连接 开发人员不必为此编写大量代码而负担沉重 与数据库进行交互。

• 它提供了查询模型的通用查询语法，而不是 数据库，然后将这些查询转换为查询 数据库可以理解。

• 它提供了一种跟踪模型对象更改的机制 因为它们在应用程序中使用，并处理更新 数据库。

Answer 3

如果你正在进行交互式数据操作，那么应该使用ORMs Object-Relational-Mapper，例如EntityFramework，典型的OLTP应用程序可以大大减少所需的代码行数，而不是像普通的ADO.NET API（使用动态SQL或存储过程调用）。 ORM确实有性能损失，但是，在交互式系统中，这种性能损失一方面可以忽略不计，因为“笨拙的工作”大大减少，另一方面，因为产生最大性能损失的元素是人与系统的互动

另一方面，如果你需要进行繁重的批量处理复杂的东西，它将从某些表中运行并将其放入其他表中，而无需任何交互式用户干预，那么性能损失ORM方法变得引人注目，在这种情况下，它可以避免从数据库内存空间中取出内容，并且使用存储过程的性能优势最终变得明显。

总的来说：

• 将ORM用于互动内容
• 对非交互式批处理使用存储过程