我想创建一个可以与任何类型的SQL提供程序一起使用的数据访问层。我不想要的是有一个switch语句，它指定了获取每个已知提供者的最后创建记录的id的不同方法。 DbConnection是否提供了以通用方式访问最后创建的记录的id的方法？
答案 0 :(得分：2)
我不会对此感到乐观。某些数据库提供了创建ID值的自动化（例如，SQL Server，MySQL）。但是，连接不会自动为您提供价值;你必须要求它。在SQL Server中，
INSERT INTO FOO (...) VALUES(...); SELECT SCOPE_IDENTITY;
Oracle甚至没有标识列的概念。生成标识值意味着要么使用现有标识值的MAX + 1，要么使用SEQUENCE和TRIGGER来添加标识值。无论哪种方式，您都必须将它全部包装在事务中以保证正确性，对于SEQUENCE解决方案，您必须运行单独的SELECT以获取序列值（作为事务的一部分）。您可能也必须使用MAX + 1方法，但我没有在任何应用程序中都朝着那个方向发展，所以我无法明确地说出来。具有自动身份解决方案的数据库不需要事务来包装每个insert-with-identity-request。
通常，数据库倾向于支持SQL的方言，而不是单一的“标准”，并且在访问方法方面它们的变化更大。试图支持“共同子集”可能意味着您将可能性缩小到太远而无法使用。采用DbConnection，DbCommand等方法，您只能在应用程序代码中生成GUID，作为摆脱标识列混乱的唯一选择。
另一个解决方案是ORM，它将模型映射到底层（并且隐藏得很好）的访问层。实体框架试图实现，但由于EF在模型和连接字符串之间的相互依赖性，生成连接字符串是有问题的。 Codeplex上的IQToolkit项目采用不同的方法将LINQ映射到数据库，但它仍然需要插件提供程序，它不仅提供唯一的连接实现，还需要SQL格式化程序和语言策略模块，它们将生成的SQL整形为特定的约束。数据库实现。
我对此的感觉是DbConnection是一个错误的地方去寻找一个地方开始你的共性。确保您了解需要支持的每个数据库的怪癖 - 这意味着在开始将它们包装在公共访问层之前，您必须非常熟悉它们。查看ORM足以了解它们的工作原理;他们可以提供的真正共性始于“用这个身份给我一个推荐人记录”，而不是“给我一个联系”。它们不仅隐藏连接和命令，还提供命令生成器，有时与数据库提供程序紧密协作。大多数提供的结果都是映射到表，模型或特定查询的类（例如，基于LINQ）。
如果您确实想要从应用程序的其余部分隐藏数据库的详细信息，则必须隐藏所有内容。
中的ADO.NET中的抽象数据访问类是不够的。或者你可以依靠ODBC，但这本身就是一组不同的问题，除了几乎已经过时了。