5

过去，我一直使用直接数据访问来处理对象（手动运行查询，并将结果映射到数据对象）。我知道微软目前正在推动他们的客户使用 EF 来查询数据对象。

关于这个，我有几个问题要问社区：-

  • 如果您有一个复杂的数据库，即几百个表、相当数量的存储过程、视图，那么一切都在 3NF 中。管理两个模式（一个本地 EF 模式映射和一个 DB）的负担是否值得权衡？

  • 一旦开始增加数据访问，两者的缓存比较如何？我知道在直接访问中你可以实现你想要的任何形式的缓存，EF 是否允许类似的东西？

  • 鉴于微软在大力推动产品并让人们为它们编写（SQL-NS、Linq-to-Sql）之后扼杀产品的历史，EF 发生这种情况的可能性有多大？

正如我所说，我目前正在大量使用直接访问，但正在考虑迁移（即，有新的查询向前发展，而不是全部回溯），并且正在寻求社区其​​他人关于他们观点的建议.

4

3 回答 3

4

如果您有一个复杂的数据库，即几百个表、相当数量的存储过程、视图，那么一切都在 3NF 中。管理两个模式（一个本地 EF 模式映射和一个 DB）的负担是否值得权衡？

您可以使用自动化工具来使您的 EF 架构保持最新状态，所以这并不是那么糟糕。

一旦开始增加数据访问，两者的缓存比较如何？我知道在直接访问中你可以实现你想要的任何形式的缓存，EF 是否允许类似的东西？

据我所知，是的。

鉴于微软在大力推动产品并让人们为它们编写（SQL-NS、Linq-to-Sql）之后扼杀产品的历史，EF 发生这种情况的可能性有多大？

这个问题太假设了。

我遇到的 EF 问题是它的性能。是的，你得到了快速的发展，但牺牲了性能。使用 EF 很容易编写糟糕且缓慢的代码，如果您不是 100% 知道自己在做什么，那么以后可能会遇到一些严重的性能问题（尤其是在处理数百个表时） .

我建议尝试一些 Micro-ORM 框架，例如 Dapper 或 Massive。您不会牺牲那么多性能，但它比传统的 Ado.net 方法更容易维护。

但是，嘿，这只是我，你可能喜欢 EF。

于 2012-06-17T12:14:45.463 回答
1

使用 EF 或任何其他 ORM 工具要记住的是，它只是将某些内容（在 EF 和 Linq2Entities 的情况下为 Linq 表达式树）转换为 SQL 语句。由于那里有一个额外的抽象和解析层，所以它总是比直接查询慢。然而，开发人员通常更容易使用 ORM。幸运的是，大多数 ORM（尤其不确定 EF）提供了一些在需要时仍可直接运行查询的方式。

你提到有一个“复杂”的数据库，这通常意味着有复杂的查询。这是 Linq 不喜欢的东西。例如，如果您最终有连接 13 个表的查询，并且几乎每个返回的列都传递给一个 db 函数，并且有一堆 case 语句和一堆子选择，那么几乎不可能转换到 Linq . 更简单的做法是将复杂性包装在视图中，并使用 EF 来查询视图。

从好的方面来说，EF 为开发人员提供了智能感知，因为构建了真正的类来模仿 DB。根据您的 EF 内容的布局方式，您可以将项目设置为所有类都从 DB 生成，因此如果有人编辑 DB 架构或更改列数据类型，您的 C# 代码将不再编译。使用传统的直接 SQL 查询，直到运行时（或集成测试时）才发现。

这都是权衡... IMO 最好的办法是尝试两者，看看你更喜欢哪个，或者以提供任一选项的方式构建解决方案。在我处理的最后一个应用程序中，我有一个“数据库工厂”类（工厂模式），其他数据访问类将使用它，它们可以向工厂请求一个普通的旧 ADO.NET 命令对象，或者请求ORM 对象（EF 案例中的 Context，但我使用的是 SubSonic，所以它是一个 IQueryable 实现）。这样，您可以通过 EF 进行“简单”查询，并在 SQL 中进行“复杂”查询。

于 2012-06-17T12:51:15.120 回答
1

与直接数据访问相比，EF 的主要优势在于开发人员的生产力。

很少有开发人员再编写汇编代码，我们让编译器生成它。随着 EF 等工具变得更好，我们将更多地使用它们并停止编写 SQL。

但是，有时您需要额外的控制来获得所需的性能，因此您仍然可能需要编写一些 SQL 代码。就像仍然在编写一些汇编代码一样。

转换有效的解决方案没有商业价值。您可以尝试 EF 进行新的开发。

于 2012-06-17T20:55:02.907 回答