实体数据框架 - 101

时间:2011-09-28 17:38:27

标签: asp.net vb.net entity-framework data-access-layer

我习惯在数据访问方面为我的项目使用数据集。我现在为自己设置了一个简单的应用程序,以便学习实体数据框架以及如何检索&操纵数据。

我在互联网上找到的所有教程和样本对我来说都太先进了。

任何人都可以指导我从哪里开始,这个模型有什么优势,在什么情况下我应该选择使用实体框架,以及在开始之前我应该​​做什么(基础)。

我的数据集工作正常。我有什么理由不坚持这种访问数据的方式吗?或者这是根据网站用户(速度目的等)来考虑的事情。

任何信息 - 指导将不胜感激。

提前谢谢..

3 个答案:

答案 0 :(得分:1)

你问的问题(“我什么时候应该使用ORM而不是DataSets /硬编码的SQL?”)有点过于宽泛,无法在Q& A网站上得到充分解决。但是,这里有几个要点:

  • ORM提供安全性,因为它们从数据库中的表生成类(或者反过来,如果您选择走这条路),并且您在这些类上执行代码内交互,而不是将字段和表名嵌入到你的代码。这为您提供了编译时的安全性,确保您在其部署后六个月内不会发现其中任何一个并发现它隐藏在应用程序的深处。
  • ORM提供了一种访问相关实体的更自然的方式(我可以在代码中执行'customer.Orders'或'order.Customer'之类的操作),而不是将SQL嵌入字符串或通过存储过程访问所有内容

还有一些缺点

  • 除了最简单的操作外,ORM生成的SQL可能比手工制作的SQL或存储过程慢。您使用ORM是为了安全和方便,而不是速度。
  • 很容易使用延迟加载等功能(相关实体按需加载而不是预先加载),并且在没有意识到的情况下会导致性能下降。
  • 为了充分利用ORM(意味着关系并在更新,删除和插入过程中使用它),您通常必须将整个对象带回内存而不仅仅是一部分。

答案 1 :(得分:1)

我同意Adam Robinson提出的所有要点,但我想补充一点,转向ORM(在我的情况下是EF4.0)是 所有关于开发人员的工作效率 。以前我做了所有手工编码的类和数据访问方法,并精心设计了所有数据访问的存储过程 - 坦率地说,几乎任何事情都无法击败性能 - 但所有手动编码都需要大量时间。

我保守估计,我使用EF4.0而不是旧方法将我的大部分开发工作削减了一半,而且我的用户没有注意到任何可察觉的减速。在我确实需要额外性能的少数情况下,我仍然可以手动编写一些数据访问和/或存储过程,以便在需要时获得额外的功能。

所以,在回答你的问题时,你的做事方式并没有“错误”,但是你应该通过学习ORM的整个过程,然后看看它们是否超过你的利弊。< / p>

答案 2 :(得分:0)