我是网络开发人员已有九年了。 我喜欢开发自定义CMS和纯手工编写的Web应用程序。
我没有使用ADO.NET数据访问模型，将本机SQL查询写入数据库并通过DBCommand调用存储过程。
2年后，我正在考虑迁移到ADO.NET实体框架。
我知道在生产力方面有很多优势，但我真的不喜欢/理解实体框架的工作方式。
在生产力方面，我创建了一个自动为我生成ADO.NET代码的应用程序，因此我不会浪费时间来编写ADO.NET代码。
我应该继续使用实体框架吗？
PS：我是表演爱好者。：P
PS 2：例如，我如何实现修改的预订树遍历来管理实体框架中的分层数据（例如：产品类别）？
PS 3：我使用MySql Server
修改
经过一番阅读后，我明白ADO.NET实体框架非常精彩。
它给了我们很多好处，我们必须手工制作或“复制粘贴”过去。 它带来的另一个好处是完全独立于提供商。 即使你喜欢旧的ADO.NET micanism或者你是像我这样的恐龙（：P），你可以使用EntityClient实体框架，如SqlClient，MySqlClient，并使用Entity-Sql的功能，巫师是独立于提供者。
是的，你失去了一些表现。 但是有了所有这些缓存技术，你就可以克服这一点。
正如我经常说的那样，“C很快，大会更多......但我们使用C＃/ VB.NET / Java”
非常感谢你提供了很好的建议。
答案 0 :(得分：2)
取决于。
当您被迫将对象图持久保存到关系存储时，ORM可以正常工作。更好的选择是使用对象数据库。所以：
如果您的应用程序将从使用对象数据库中受益，并且您被迫使用关系存储，那么答案很简单：是的，您需要ORM 。
如果你已经有了数据层策略并且不需要花费大量时间来使用它并且感觉很好，那么答案也很简单：你不需要ORM。，只有一个简单的“但是” ......
在尝试之前，您无法预见所有优点/缺点。没有人有你的想法和你的项目。所以更好的答案是：尝试并自己解决。
答案 1 :(得分：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，因为它会自动创建所有包装器代码，参数化查询，使其全部类型安全，并且将其重构为数据传输对象。它节省了大量的样板。
答案 2 :(得分：0)
为了回答性能的至少一个方面，EF将生成参数化查询，这有助于提高性能。参数化查询允许db存储执行计划，并允许dba在必要时优化计划。否则，db会将大多数查询视为全新的查询，因此每次都会创建一个新的执行计划。