实体框架-与Orace和SQL Server交互

你的问题似乎涉及多个问题，我将根据我的观点给出答案:

1。如何创建与数据库(DB引擎)无关的DAL?

A:一种方法是遵循Repository模式和/或使用接口将操作数据的代码与检索/插入数据的代码解耦。如果要使用ADO，代码用于获取数据的接口的实际实现也可以被定制为与DB引擎无关。. NET，你可以查看企业库中一些非常有用的代码，这些代码与数据库引擎无关。实体框架也与不同的数据库引擎兼容，但是，正如你提到的，一次只能与一个数据库交互，所以无论何时生成模型，都要将其绑定到数据库所在的数据库引擎的细节上。这与你问题中的另一个问题有关:

2。-你应该使用普通的旧ADO吗?NET还是EF?

A:这是一个非常好的问题，我相信之前已经问过很多次了，并且考虑到这两种方法都能给你带来能够检索和操纵数据的相同实际结果，由此产生的问题是:你个人对编码的偏好和项目的时间/资源限制是什么?

在我看来，实体框架最适合代码优先的项目，当你的业务逻辑不需要复杂的日志记录，事务和其他安全或性能限制在DB端，不是因为EF不能够包括这些要求，而是因为它变得相当复杂和不切实际，我个人认为这违背了EF的目的，为你提供一个工具，允许快速开发。

因此，如果参与项目的人员不太习惯用SQL编写存储过程，并且数据操作将主要围绕您的服务进行，而不需要在DB端进行非常复杂的操作，那么EF是一种合适的方法，您可以利用Repository模式以及接口来实现"DBContext"对象，这将允许您创建一个与DB无关的DAL。

然而，如果你需要实现事务、安全、广泛的日志记录，并且更擅长编写SQL存储过程，那么实体框架通常会成为你的负担，因为它还不适合高级任务，例如:

• 假设你有一个User表，有多个字段(地址，电话等)，这些字段对于所有与用户相关的操作(如身份验证)并不总是必需的;尝试将实体映射到不返回实体包含的任何字段的存储过程的结果将导致错误，并且您可能需要创建具有更多或更少成员的不同模型，或者在SP中返回特定操作可能不需要的额外列，从而不必要地增加带宽消耗。

• 另一种情况是利用SQL Server中的表值参数等功能来优化一次向DB发送多个记录，在这种情况下，实体框架不包括任何会自动优化多个记录操作的东西，所以为了使用tvp，你需要手动定义该操作，就像你去ADO一样。净路线。

最终，您将不得不权衡您的项目的考虑与您的替代方案提供给您的;ADO。. NET为你的数据库操作提供了最好的性能和定制，它是高度可扩展的，允许优化，但它需要更多的时间来编码，而EF对于对象操作是非常直接和实用的，尽管它在不断发展和改进，但它的性能和功能与ADO并不完全匹配。净。

关于驱动程序的问题，它不应该太重要，因为即使是Oracle也鼓励你使用他们的驱动程序，而不是微软提供的默认驱动程序。