我正在开发.NET Web api服务（支持Odata）以支持Mobile客户端。该服务应同时支持Oracle和SQL Server数据库，但是一次使用一种数据库类型，具体取决于哪种数据库技术客户端正在使用。
如何创建数据库不可知数据访问层？不想两次编写代码-一次用于SQL Server，一次用于Oracle。
同样，为了在EF中支持oracle，需要第3方oracle驱动程序-来自devart或oracle的ODP.NET。
我正在辩论应该使用旧样式的ADO.NET还是使用EF构建数据访问层。
我将不胜感激。
谢谢！
最佳答案
您的问题似乎围绕多个问题，我将根据对这些问题的看法给出答案：
1.-¿如何创建与数据库（数据库引擎）无关的DAL？
答：一种解决方法是遵循Repository模式和/或使用接口将处理数据的代码与检索/插入数据的代码分离。您的代码用于获取数据的接口的实际实现也可以与DB Engine无关，如果您要使用ADO.NET，则可以查看Enterprise Library以获得一些非常有用的代码，数据库引擎不可知。实体框架还与不同的数据库引擎兼容，但是，正如您提到的，一次只能与一个数据库交互，因此，只要生成模型，就将其与数据库所托管的数据库引擎的细节相关联。与您的问题中的另一个问题有关：
2.-¿您应该使用普通的旧ADO.NET还是EF？
答：这是一个非常好的问题，我确信已经问过很多次了，并且考虑到这两种方法都可以为您提供检索和处理数据的相同实际结果，因此得出的问题是：'您的个人情况是什么？对编码的偏好以及项目的时间/资源约束？
IMO，实体框架最适合于“代码优先”项目，并且当您的业务逻辑不需要数据库端的复杂日志记录，事务和其他安全性或性能约束时，这不是因为EF无法满足这些要求，而是因为它变得相当复杂且不切实际，我个人认为这违背了EF的宗旨，无法为您提供可以快速发展的工具。
因此，如果参与该项目的人员不太喜欢用SQL编写存储过程，并且数据操作将主要围绕您的服务进行，而无需在DB端进行非常复杂的操作，那么EF是一种合适的方法，您可以利用存储库模式以及接口来实现“ DBContext”对象，该对象将允许您创建数据库不可知的DAL。
但是，如果您需要实现事务，安全性，广泛的日志记录，并且更舒适地编写SQL存储过程，则Entity Framework通常会被证明是您的负担，因为它尚不适合高级任务，例如：
假设您有一个用户表，其中包含多个字段（地址，电话等），这些字段对于所有与用户相关的操作（例如身份验证）并不总是必需的；尝试将实体映射到不返回该实体包含的任何字段的存储过程的结果将导致错误，并且您将需要创建具有更多或更少成员的不同模型，或者在您可能不需要执行特定操作的SP，从而不必要地增加了带宽消耗。
另一种情况是利用诸如SQL Server中的表值参数之类的功能来优化一次向数据库发送多个记录的情况，在这种情况下，实体框架不包含任何会自动优化对多个记录的操作的东西，因此为了使用TVP您将需要手动定义该操作，就像您走了ADO.NET路由一样。
最终，您将不得不权衡您的项目考虑因素和备选方案所提供的内容。 ADO.NET为您的数据库操作提供最佳的性能和自定义，它具有高度的可伸缩性并允许进行优化，但是需要花费更多的时间进行编码，而EF对于对象操作非常简单实用，尽管它不断发展和改进，它的性能和功能还不能与ADO.NET相提并论。
而且关于驱动程序问题，在此事上不应考虑太多，因为甚至Oracle都鼓励您使用其驱动程序而不是Microsoft提供的默认驱动程序。
关于c# - Entity Framework -与Oracle和SQL Server交互，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24960517/