实体框架是一种非常耗时的方式来节省一点时间吗？

Question

我在实体框架上有一个1000多页的章节，并且气馁并回到了旧的存储过程。

实体框架的共识（如果有的话）是什么？听完已经完成基于EF的项目的人们会很有意思，看看他们是否认为值得付出全部努力。

我一直在修补T4模板，并找到了一种方法来生成我的SPROC和DTO，就像我喜欢它们一样，而不会弄乱EF。我错过了什么吗？

Answer 1

我个人喜欢使用Entity框架实现LINQ的抽象和轻松集成，在生产力方面，拥有ORM而不是直接与SQL服务器交互是非常重要的。

另一方面它并不完整 - 对于任何需要批量处理的东西，即大表删除或全文搜索，你仍然需要存储查询 - 但至少它最小化了我必须的数量处理这些情况。

Answer 2

  

我一直在修补T4模板，并找到了一种方法来生成我的SPROC和DTO，就像我喜欢它们一样，而不会弄乱EF。我错过了什么吗？

不一定。您描述的过程是任何ORM背后的基本推理。

实体框架提供了T4模板可能没有的一些内容：

1. Microsoft标准的创建数据类的方法
2. 扩展到大型应用程序的能力
3. 使用相同代码支持不同数据存储的能力。
4. 灵活性

EF是更大图片的一部分，包括内置数据验证，延迟加载，多层设计和可测试性等内容。如果您正在构建永远不会扩展到更大应用程序的非常小的应用程序，那么您可能不需要这些东西。

Answer 3

任何ORM都有明显的学习曲线。 值得坚持下去，你最终会在这个过程中找到一些里程碑，在这个过程中你会真正看到灵活的ORM如EF或NHibernate的好处。

你基本上是在学习一个复杂的API，一旦你熟练掌握它，你节省的时间会使你投入的时间相形见绌。这是假设您继续将其用于将来的应用程序。

Answer 4

对于基本的CRUD应用程序，实体框架或任何体面的ORM将为您节省大量时间。是的，有一个学习曲线。与大多数技术一样，您可以使用您所知道的内容，也可以投资以学习更好的内容。 ORM肯定更好。

您的sproc是否返回数据读取器或数据集？您编写了多少代码（使用T4或不使用T4）将该数据读取器/集合转换为对象类？最后，如果你不使用现成的ORM，你通常最终必须建立自己的，这是一个巨大的错误。

您是如何决定在sprocs和应用程序类之间拆分业务逻辑（针对非CRUD方案）的？使用ORM，业务逻辑几乎不会被拆分，它都属于应用程序类，这更容易维护。

我已经完成了两种方式，并且T4离开很多作为数据层解决方案。

即使使用ORM，也有使用sprocs的场景（性能或其他），这没关系，但是对于拥有数百个表的数据库，你可能永远不会需要少数几个sprocs。

ORM提供了许多您今天可能不需要的功能，但是您会很高兴您不需要在需要时自行构建它们。