我正在开发一个 .NET web api 服务（支持 Odata）来支持移动客户端。该服务应该支持 Oracle 和 SQL 服务器数据库，但一次只能使用一种数据库类型，根据哪一种数据库技术客户端正在使用。
如何创建与数据库无关的数据访问层？不想编写两次代码 - 一次用于 SQL Server，一次用于 Oracle。
此外，为了在 EF 中支持 oracle，似乎需要第 3 方 oracle 驱动程序 - 来自 devart 或 oracle 的 ODP.NET。
我正在讨论应该使用旧式 ADO.NET 还是使用 EF 来构建数据访问层。
我将不胜感激这方面的任何帮助。
谢谢！
【问题讨论】：
标签： c# sql-server oracle entity-framework architecture
您的问题似乎围绕着多个问题，我将根据我对它们的看法给出答案：
1.- ¿如何创建与数据库（数据库引擎）无关的 DAL？
答：一种方法是遵循Repository 模式和/或使用接口将操作数据的代码与检索/插入数据的代码分离。您的代码用于获取数据的接口的实际实现也可以定制为与 DB 引擎无关，如果您要使用 ADO.NET，您可以查看Enterprise Library 以获得一些非常有用的代码数据库引擎不可知。实体框架还与不同的数据库引擎兼容，但正如您所提到的，一次只能与一个数据库交互，因此无论何时生成模型，您都将其与您的数据库所在的数据库引擎的细节联系起来。这个与您问题中的另一个问题有关：
2.- ¿您应该使用普通的旧 ADO.NET 还是 EF？
答：这是一个非常好的问题，我敢肯定，我之前已经多次问过这个问题，并且鉴于这两种方法都能为您提供相同的实际结果，即能够检索和操作数据，因此产生的问题是：¿您个人对编码的偏好以及项目的时间/资源限制？
IMO，实体框架最适合 Code-First 项目，并且当您的业务逻辑不需要数据库端的复杂日志记录、事务和其他安全或性能限制时，不是因为 EF 无法包含这些要求，但是因为这样做变得相当复杂和不切实际，而且我个人认为这违背了 EF 的目的，即为您提供一个允许快速开发的工具。
因此，如果参与项目的人员不太习惯用 SQL 编写存储过程，并且数据操作将主要围绕您的服务进行，而不需要在 DB 端进行非常复杂的操作，那么 EF 是一种合适的方法，并且您可以利用存储库模式和接口来实现“DBContext”对象，这些对象将允许您创建与 DB 无关的 DAL。
但是，如果您需要实现事务、安全性、大量日志记录，并且更愿意编写 SQL 存储过程，那么 Entity Framework 通常会成为您的负担，因为它还不适合高级任务，例如示例：
假设您有一个 User 表，其中包含多个字段（地址、电话等），这些字段对于所有与用户相关的操作（例如身份验证）并不总是必需的；尝试将实体映射到不返回实体包含的任何字段的存储过程的结果将导致错误，您将需要创建具有更多或更少成员的不同模型，或者在特定操作可能不需要的 SP，从而不必要地增加了带宽消耗。
另一种情况是利用 SQL Server 中的表值参数等功能来优化一次将多条记录发送到数据库，在这种情况下，实体框架不包括任何会自动优化多条记录操作的东西，因此，为了使用 TVP，您需要手动定义该操作，就像您使用 ADO.NET 路线时所做的那样。
最终，您将不得不权衡您项目的考虑因素和您的替代方案为您提供的内容； ADO.NET 为您的数据库操作提供最佳性能和自定义，它具有高度可扩展性并允许优化，但需要更多时间编写代码，而 EF 对于对象操作非常简单实用，尽管它在不断发展和改进，它的性能和功能还不能与 ADO.NET 完全匹配。
关于驱动程序问题，它不应该在这件事上占太大的比重，因为即使是 Oracle 也鼓励您使用他们的驱动程序而不是 Microsoft 提供的默认驱动程序。
【讨论】：