在连接到多个可能的数据源(与数据库无关)方面,C#中的每个上述数据库连接方法的主要优点是什么?另外在性能方面可能会提供最佳性能?
最后有什么理由可以避免使用与数据库无关的应用程序的特定方法吗?
我问的原因是因为我的应用程序目前使用Ole而且我在使用工厂连接到某些数据库时遇到了一些问题,因此我正在研究替代方案。我听说Odbc比Ole慢,但这背后是否有任何真相,它在现实世界的应用程序中是否真的引人注目?
我对此主题感兴趣的原因如下:
我对当前项目的要求表明,我必须拥有一个能够在不事先了解所述数据库的情况下连接到任何数据库的工作数据访问层。因此,就连接而言,我无法对任何给定数据库的特定内容进行硬编码。已经使用sql查询工厂类型概念处理了对每个给定数据库运行方言特定语句。绑定变量的替换和格式化也是如此。
更新:目前我现在有一个使用ADO.net和数据库提供程序工厂的代码的工作版本。这意味着我正在使用Adam Houldsworth建议的基类。提供程序在providerName属性下的连接字符串中指定。连接字符串存储在app.config中,可以通过我的数据库连接类检索它。如果已经安装了正确的驱动程序,如npgsql或Oracle的odac包,那么工厂将正常工作。下面是我的代码示例,显示了使用提供程序工厂的连接对象的基本构造函数。
private readonly DbFactoryBindVariables m_bindVariables;
private readonly DbProviderFactory m_provider;
private string m_connectionString = String.Empty;
private readonly string m_providerName = String.Empty;
private DbConnection m_dbFactoryDatabaseConnection;
/// <summary>
/// Default constructor for DbFactoryDatabaseConnection.
/// </summary>
public DbProviderFactoryConnection()
{
m_providerName = ConfigurationManager.ConnectionStrings["ApplicationDefault"].ProviderName;
m_provider = DbProviderFactories.GetFactory(m_providerName);
m_dbFactoryDatabaseConnection = m_provider.CreateConnection();
m_connectionString = ConfigurationManager.ConnectionStrings["ApplicationDefault"].ConnectionString;
m_dbFactoryDatabaseConnection.ConnectionString = m_connectionString;
m_bindVariables = new DbFactoryBindVariables(m_dialect.ToLower(), DbFactoryBindSyntaxLoader.Load(this));
}
如果您所选择的.net框架版本的machine.config中尚未包含类似于以下内容的内容,则可能需要将其添加到app.config或web.config中。
<system.data>
<DbProviderFactories>
<add name="Npgsql Data Provider"
invariant="Npgsql"
support="FF"
description=".Net Framework Data Provider for Postgresql Server"
type="Npgsql.NpgsqlFactory, Npgsql, Version=2.0.1.0, Culture=neutral,
PublicKeyToken=5d8b90d52f46fda7" />
</DbProviderFactories>
</system.data>
需要连接字符串:
<add name="ApplicationDefault" connectionString="DATA SOURCE=TNSNAME;PASSWORD=PASS;USER ID=USER;" providerName="Oracle.DataAccess.Client;"/>
在此阶段,如果在配置应用程序的客户端版本时使用了正确的连接字符串,我现在可以完全与数据库无关。
答案 0 :(得分:5)
我会避免抽象与数据库的连接,因为你总是以最低的公分为目标。相反,尝试抽象保存实体的要求。然后,该抽象的每个实现都可以是特定于数据库的(基本上是针对接口的编程)。
也就是说,我曾经历过一个需要支持多个数据库的实例,这是一项艰难的要求。在这种情况下,所有这些恶化都会遇到YAGNI的口头禅。
关于将OLE DB与ODBC进行比较的问题通常可以在这里找到:
what is the difference between OLE DB and ODBC data sources?
虽然提前询问性能问题是一件好事,但在您的应用程序环境中无法回答这个问题。不幸的是,只有对样本数据进行分析才能为您提供所需的答案。
关于DbConnection
没什么值得注意的,它是其他特定于数据库的连接类的基类。
您是否考虑过像NHibernate这样的ORM或像Enterprise Library Data Access Application Block这样的框架?这些将帮助您抽象数据库(使用ORM,甚至不需要在数据库中进行任何编码)。
更新:到目前为止我从评论中可以看出,好像你唯一的选择就是使用提供的.NET基类(例如DbConnection
)或接口( IDbConnection
)。据我所知,没有任何东西可以为您提供连接字符串的正确连接,因此您可能必须对该部分进行编码。这样,您可以在检测到连接字符串时返回OleDbConnection
,OdbcConnection
,SqlConnection
等,但在代码DbConnection
或IDbConnection
中使用它们,从而使您的代码与底层数据库无关。
不理想,但完全可行。
答案 1 :(得分:3)
如果您需要具有不可知的数据访问层,而不需要多次编码数据访问,则使用DbProviderFactory
是一个不错的选择。
我认为您没有任何理由想要避免它,并且使用System.Data.Common
上的基类涵盖了所有必要的功能。
我们在Nearforums上使用不可知的数据访问,因为我们提供SQL Server和MySql数据库脚本。关于性能,它取决于不同公司/社区提供的特定连接器(Oracle,MySql,PostgreSQL,...)实现。大多数已知的连接器在几年内都经过了适当的测试。