客户想要使用仍然是不可知的。最初我们计划支持MySQL、Oracle和SQLServer。表和视图很简单，查询（没有真正花哨的SQL），因此问题：使用本机数据库驱动程序（MySQLDbConnection等）并封装执行查询和处理结果的逻辑或使用通用OleDbConnection显然，选项2不涉及任何开销，但我认为性能不如本机访问？注意：如果您决定使用基本的ADO.NET2功能而不是ORM（例如EntityFramework或NHibernate）或LINQtoSQL，则此答案是相关的。假设您在app.config中定义了一个连接字符串：请注意providerName属性及其值的存在。您还可以为另一个数据库提供程序输入一个值，例如System.Data.SQLite。（请注意，非标准提供程序，即默认情况下不在.NETFramework中的提供程序，需要首先位于app.config或客户端机器的machine.config中。)现在您可以像这样以完全独立于提供者的方式使用指定的数据库：usingSystem.Configuration；//对于使用System.Data的ConfigurationManager；//对于使用System.Data.Common的所有接口类型；//对于DbProviderFactoriesvarcs=ConfigurationManager.ConnectionStrings["SomeConnection"];//^^^^^^^^^^^^^^^^varfactory=DbProviderFactories.GetFactory(cs.ProviderName);//^^^^^^^^^^^^^^^使用(IDbConnectionconnection=factory.CreateConnection()){connection.ConnectionString=cs.ConnectionString;//^^^^^^^^^^^^^^^^^^^^^^connection.Open();try{using(IDbCommandcommand=connection.CreateCommand()){...//对数据库做一些事情}}finally{connection.Close();}}请注意，此代码仅适用于接口类型。您指定特定数据库提供程序的唯一位置是通过app.config文件中的providerName属性值。（我已经用^^^s标记了app.config设置的所有位置。）进一步阅读：恕我直言，使用ORM是一个很好的设计决策，以便拥有与数据库无关的应用程序。切换数据库就像更改配置设置和连接字符串一样简单。您不需要OleDbConnection来访问非特定的ADO.NET提供程序。只需使用DbConnection等人。有关详细信息，请参阅MSDN上的DbProviderFactories。通过将Oracle包括在该列表中，您可以保证它不会那么简单。换句话说，您的应用程序不能与数据库无关。如果您不使用ORM，您肯定希望构建一个数据访问层，以对您的应用程序的其余部分隐藏所有这些。这里说一点经验。只是说'。对于跨SQLServer和Oracle的通用模式，我们必须构建ORM的大部分基础架构，同时避免可能降低性能的方面。肯定有趣但不平凡！LINQ是一个备受推崇的.NETORM，部分原因是您可以将它与存储过程一起使用。问题是，它只是SQLServer，但人们正在为Oracle和MySQL开发类似的功能。对于数据库和查询优化，我对使用ORM的想法感到畏惧。SQL中的数据类型、函数和整体语法不是很便携。与每个数据库交互的最有效方式是为每个数据库定制模型和查询，但这意味着专业知识、时间和金钱。如果需要，专注于一个具有代码设置的数据库供应商以支持供应商交换，并根据需要添加对其他数据库的支持。没有充分的理由避免使用最广泛支持和最通用的接口-OleDb甚至ODBC，如果您对它们感到满意的话。超出此范围的任何事情都会减少您可用的产品/语言/平台/工具/开发人员基础。由于最接近SQLmetal，供应商不会引入太多低效率——当然比更深奥的选项要少。他们花了很长时间来解决任何问题。如果您要添加一个抽象层（您自己的或其他人的），那么这应该根据在您的特定上下文中引入的抽象的优点来决定，而不仅仅是拥有一个（这只是更多的支持，除非它是有意的好处.)如您所见，每个人的里程数各不相同。:)但总的来说，我认为越简单越好。为什么不使用MicrosoftPatternsandPracticesEnterpriseLibraryDataAccessApplicationBlock。非常简单，开销和切换供应商最少。引用：数据访问应用程序块利用这些类并为封装特定于数据库类型的功能（例如参数发现和类型转换）的模型提供进一步支持。因此，应用程序可以从一种数据库类型移植到另一种数据库类型，而无需修改客户端代码。通过让大量应用程序将DAL用作一组接口，您始终可以使应用程序的一部分数据库不可知。然后，DAL本身将为目标数据库提供具体的实现。通过这种方式，您可以脱离DAL的使用，但可以享受DAL中性能改进或供应商特定构造的好处。以上就是C#学习教程：KeepingApplicationDatabaseAgnostic(ADO.NETandEncapsulatingDBLogic)分享的全部内容。收藏不代表立场，如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
