实体数据框架 - 101

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

我在互联网上找到的所有教程和示例都对我来说太过先进。

任何人都可以指导我从哪里开始，这个模型的优点是什么，在什么情况下我应该选择使用实体框架，以及在开始之前我应该使用哪些事物（基础）。

我的数据组工作正常。我有没有理由不坚持这种访问数据的方式？或者这是根据网站的用户需要考虑的事情（用于速度等）

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

预先感谢您..

来源

2011-09-28 Kemal Emin

这个问题太广泛了。为了贯穿你的全部观点，人们可以撰写小论文。 –

你问（“当我应该使用ORM，而不是数据集/硬编码SQL？”）是有点过于宽泛，可以在Q充分解决的问题&一个网站。但是，这里有一对夫妇的高点：

ORM的提供安全性，因为它们产生在你的数据库中的表类（或周围的其他方法，你应该选择走这条路），你执行你的这些类的代码交互，而不是将字段和表名嵌入到代码中。这为您提供了编译时安全性，确保您不会发现其中的一个，并在部署后六个月内发现它隐藏在应用程序的隐藏深处。
ORM的规定获取相关实体（我可以做这样的事情“customer.Orders”或代码“order.Customer”），而不是要么嵌入SQL字符串中或通过访问所有存储过程的更自然的方式

和几个缺点

在所有，但最简单的操作，ORM生成SQL很可能是比手工制作的SQL或存储过程较慢。为了安全和方便，您使用ORM，而不是速度。
使用懒惰加载（相关实体按需加载而不是预先加载）等功能很容易，并且在未意识到的情况下会产生性能损失。
为了充分利用ORM（意义关系并在整个更新，删除和插入过程中使用它），通常必须将整个对象带回到内存中，而不仅仅是一部分。

来源

2011-09-28 17:48:28

我认为你对ORM的判断过于苛刻。有一个重要的学习曲线，但如果开发人员知道他们在做什么，一个好的ORM并不真的存在这些问题。当然任何技术都可能以不好的方式使用，特别是如果开发人员懒惰。我认为ORM有缺点，但不是你列出的。 –

@MichaelMaddox：除了最简单的操作之外，ORM生成的SQL几乎普遍比手工制作的SQL慢。例如，急切的加载通常是（如果不是总是）通过创建所有涉及表的笛卡尔积来完成的，然后在客户端将其卷起来。这可能会导致*巨大*结果集充满了从服务器返回的重复数据。另外，我不了解任何可以在内存中没有相应对象的情况下执行DML的ORM，尽管有一些（不直观的）方式来解决这个问题（比如“伪造”一个对象并将它附加到ORM的上下文中）。 –

我非常赞成ORM。我在我的项目中使用了EF4，并没有任何其他方式，但它们并不代表某些人认为他们所做的那种头脑清晰的选择。它们与其他任何东西都有优点和缺点，只是查询速度的差异通常不如生产力和开发时间的增加重要。 –

我同意亚当·罗宾逊提出的所有问题，但我会然而，此举增加，到ORM（在我的情况EF4.0）是所有关于开发人员的生产力。以前，我做了所有手工编码的类和数据访问方法，并为所有数据访问精心设计了存储过程 - 坦率地说，性能无法胜任任何事情 - 但所有手工编码都需要大量时间。

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

所以，在回答你的问题时，你的做事方式没有什么“错误”，但是你应该通过学习ORM的整个过程，然后看看他们是否优于你。

来源

2011-09-28 18:12:07

ORMs（任何ORM）的学习曲线很重要。不要让过程开始时简单的代码生成欺骗你。

如果有人知道ORM和数据集，我认为他们会选择ORM 99％的时间，优点是非常有吸引力。 ORM并不完美，但几乎在每种情况下都比数据集更好。也就是说，如果数据集正在为你工作，并且ORMs的学习曲线正在困扰着你，那么坚持使用数据集是完全可以的。我会鼓励你继续打开ORM的学习曲线，即使需要花费数年的时间来开展和关闭研究（也可能）。

来源

2011-09-29 08:58:06

实体数据框架 - 101

回答

相关问题