我担任网络开发人员已有九年了。 我喜欢开发自定义 CMS 和纯手工编码的 Web 应用程序。
我对 ADO.NET 数据访问模型很满意，可以将 native SQL 查询写入数据库并通过 DBCommand 调用存储过程。
两年前我一直在考虑迁移到 ADO.NET Entity Framework 。
我知道在生产力方面有很多优势，但我真的不喜欢/理解 Entity Framework 的工作方式。
就生产力而言，我创建了一个应用程序，可以自动为我生成 ADO.NET 代码，这样我就不会浪费太多时间来编写 ADO.NET 代码。
我应该转向 Entity Framework 吗？
PS:我是一个表演爱好者。:P
PS 2:例如，我如何实现修改的预序树遍历来管理 Entity Framework 中的分层数据(例如:产品类别)？
PS 3:我使用 MySql 服务器
编辑
经过一番阅读后，我了解到 ADO.NET Entity Framework 非常棒。
它给我们带来了很多过去必须手工制作或“复制粘贴”的好处。 它带来的另一个好处是完全独立于提供商。 即使您喜欢旧的 ADO.NET micanism 或者您是像我一样的恐龙 (:P)，您也可以使用像 SqlClient、MySqlClient 这样的 EntityClient 的 Entity Framework ，并使用独立于提供者的 Entity-Sql 的强大功能。
是的，你会失去一些性能。 但有了所有这些缓存技术，您就可以克服这个问题。
正如我常说的，“C 很快，汇编更快......但我们使用 C#/VB.NET/Java”
非常感谢您的好建议。
最佳答案
这取决于。
当您被迫将对象图持久保存到关系存储时，ORM 可以很好地发挥作用。更好的选择是使用对象数据库。所以:
如果您的应用程序将受益于使用对象数据库，而您被迫使用关系存储，那么答案很简单:是的，您需要 ORM。
如果您已经有了数据层策略，并且不需要花费大量时间使用它并且您觉得它很好，那么答案也很简单:您不需要 ORM。，有一个简单的“但是”...
在尝试之前，您无法预见所有优点/缺点。没有人了解你的想法和你的项目。所以更好的答案是:尝试一下并自己找出答案。
关于c# - 从 ADO.NET 迁移到 ADO.NET Entity Framework ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8767490/