实体框架矫枉过正？

Question

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

• 编写一个可以在其他项目上使用的定制数据访问组件
• 使用Microsoft的企业库数据访问应用程序块 - 但是，由于源是Oracle并且想要使用ODP，这可能还需要使用Enterprise Library Contrib吗？
• 使用ORM，例如Entity Framework
• 其他替代方案？

我倾向于选项2，虽然看起来我还需要使用Contrib？我认为将实体框架用于这样一个相当简单的解决方案没有多大好处，特别是在必须与SP集成时？

或者我错过了什么？

由于

Answer 1

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

Answer 2

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