实体框架矫枉过正？答案

【问题标题】：Entity Framework Overkill?实体框架矫枉过正？
【发布时间】：2011-11-08 17:44:16
【问题描述】：

所以我有一个项目，我们有一些数据访问要求。这相当简单，我们只想检索从存储过程（这已经存在）返回的数据并更新几个表。我猜我的选择是：

编写可用于其他项目的定制数据访问组件
使用 Microsoft 的 Enterprise Library Data Access Application Block - 但是，由于源是 Oracle，并且想要使用 ODP，这可能还需要使用 Enterprise Library Contrib？
使用 ORM，例如实体框架
其他选择？

我倾向于选项 2，尽管我似乎还需要使用 Contrib？我认为将实体框架用于这样一个相当简单的解决方案并没有太多好处，尤其是在必须与 SP 集成时？

还是我错过了什么？

谢谢

【问题讨论】：

【解决方案1】：

我会认真考虑使用微型 ORM，例如 dapper、mass、Simple.Data、peta-poco 等。这使得调用 proc 和处理网格变得容易，而没有完整的复杂性和开销甲骨文。我知道 dapper 可以同时使用 oracle 和 procs。

【讨论】：

为什么不简单地使用企业图书馆数据访问应用程序块？
@Jon 因为我以前用过它；p 这有点尴尬，坦率地说，与直接使用 ADO.NET 相比并没有增加太多。另一方面，dapper 确实 - 即为您处理所有参数化和具体化微不足道。
当我们试图尽可能标准化时，问题将是引入另一个 ORM。
@Jon 好吧，你确实说过，我引用了“其他选择？”，而 EF 你确实说过“例如”。如果你不能使用它，没关系。但请注意 - 它不是（完整的）ORM - 它只是 ADO.NET 的非常友好（和快速）的包装器。哎呀，这是一个文件；p
好的，我会检查一下，我同意我正在寻找其他替代方案。感谢您的帮助。

【解决方案2】：

存储过程和表是否都在同一个oracle db中？如果是这样，为什么不写一点pl/sql？

【讨论】：

会有 PL SQL，但在 .NET 级别，我希望更容易调用 Oracle dB，而不是 ODP 中的重复代码。另外，我希望在物理数据库之上有一层抽象。
@Jon 我不知道你的应用程序，但它似乎有点矫枉过正，我想问你为什么要在数据库上加一层抽象？使用 db 有什么问题 - 我要问的问题是弹出一个程序需要多长时间与添加一个替代方案需要多长时间，以及是否有好处。如果还有其他原因，那很好，但是对于您所说的问题，当需要几个小时才能弹出 pl/sql 块时，我发现很难证明另一种解决方案的合理性
即使使用 SP，您仍然需要在 .NET 中编写代码来执行数据访问，这可能很麻烦。使用 Microsoft 的企业库数据访问应用程序块或 ORM 之类的东西可以使您免受这种情况的影响并提高工作效率。
@Jon 在你的问题中你说你只这样做了一次 - 引入一个全新的库来更新几个表似乎有点矫枉过正，我怀疑你还有其他事情要做。
啊，好吧，我知道这可能有点误导，抱歉。可能需要执行的操作不止一项。但是，仍然不是很大的数量。