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

时间:2012-07-14 18:03:06

标签: sql-server entity-framework entity-framework-4

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

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

编辑:

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

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

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

3 个答案:

答案 0 :(得分:5)

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

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

答案 1 :(得分:4)

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

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

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

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

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

答案 2 :(得分:2)

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

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

总的来说:

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