从ADO.NET到ADO.NET实体框架

Question

我已经做了九年的网页开发人员了。我喜欢开发自定义CMS和purly手工编码的web应用程序。

我同意ADO.NET数据访问模型，将原生SQL查询写入数据库，并通过DBCommand调用存储过程。

两年来，我一直在考虑转向ADO.NET实体框架。

我知道在生产力方面有很多优点，但我真的不喜欢/理解它的实体框架的工作方式。

在效率方面，我创建了一个自动为我生成ADO.NET代码的应用程序，这样我就不会浪费时间编写ADO.NET代码。

我应该在实体框架上移动吗？

PS :我是一个表演爱好者。

PS 2:例如，我如何实现修改过的预顺序树遍历，以管理实体框架中的层次数据(例如:产品类别)？

PS 3:我使用MySql服务器

编辑

经过一段时间的阅读，我了解到ADO.NET实体框架是非常棒的。

它给了我们很多好处，我们必须手工制作或“复制粘贴”在过去。它带来的另一个好处是完全独立于提供者。即使您喜欢旧的ADO.NET麦克风，或者您是像我这样的恐龙(：P)，您也可以使用EntityClient (如SqlClient )、MySqlClient等实体框架，并使用实体的力量--SQL女巫是独立于提供者的。

是的，你失去了一些表演。但是有了这些缓存技术，你就能克服这一问题。

正如我常说的，“C是快速的，组装甚至是more...but我们使用C#/VB.NET/Java”

非常感谢穆奇的好建议。

Answer 1

在大多数情况下，ORM的选择不会改变您的数据模型。您可以使用与以前完全相同的方法，但现在可以在代码中而不是在SQL中使用它们。

在MPTT示例中，您将执行相同的操作，但是在食物树中，它将类似于这样的情况，其中根项左值为1，右项为20。

var query = from f in food where lft > 1 and rgt < 20 select f.name;

更重要的是，如果您确实发现了一些在ORM中做得不太好的事情，那么始终可以使用ORM调用在SQL中所需的sproc。

事实上，即使我没有使用ORM来映射表，我仍然会使用它来调用我的sprocs，因为它将自动创建所有包装程序代码，参数化查询，使所有类型都安全，并将其重组为数据传输对象。这样就省去了写很多样板。

Answer 2

那得看情况。

当您被迫将对象图持久化到关系存储时，ORMs工作得很好。更好的选择是使用对象数据库。所以：

如果您的应用程序将受益于使用对象数据库，并且您被迫使用关系存储，那么回答很简单:是的，您需要ORM。

如果您已经有了数据层策略，并且不需要花费大量时间使用它，并且觉得它很好，那么答案也很简单：您不需要ORM.，只有一个简单的“但是”。

除非你尝试，否则你不可能预见到所有的优点/缺点。没有人有你的头脑和你的计划。因此，更好的答案是：尝试并自己解决它。

Answer 3

要回答至少一个方面的性能，EF将生成参数化查询，这对性能很好。参数化查询允许数据库存储执行计划，并允许dba在必要时优化计划。否则，大多数查询都被db视为全新的，因此每次都会创建一个新的执行计划。