ASP.NET:如何在一个应用程序中支持两种数据库类型? (访问、MS SQL Server 2008 Express)
我正在开发的 ASP.NET Web 应用程序需要支持两种不同类型的数据库,即 Access 和 MS SQL Server 2008 Express。
我已经在 web.config 中存储了每种数据库类型的连接字符串,并且还有另一个 web.config 值来指定要使用的值。所以我可以毫无问题地获得正确的连接字符串。
最大的问题来自于数据库对象。对于我已经实现的 Access,我在代码中使用对象 OleDbConnection、OleDbCommand 和 OleDbDataReader 来进行数据库调用。
看来对于 SQL Server,我无法使用这些对象,而是需要使用对象 SqlConnection、SqlCommand 和 SqlDataReader 来完成基本相同的操作。
我想尽可能多地重用当前的代码,而不必为每种数据库类型创建两个单独的块。 (我有很多采用 OleDbDataReader 作为参数的方法 - 例如,我不想为每个方法创建 2 个。)
我注意到连接对象都继承自 DbConnection。对于数据读取器 (DbDataReader) 和命令 (DbCommand) 也是如此。
是否可以采用我现有的 Access 代码,用 Db 对象替换所有 Ole 对象,然后根据当前数据库类型将这些对象转换为正确的类型?
是否有在一个 ASP.NET 应用程序中支持两种数据库类型的最佳实践?
如果有帮助的话,我可以添加一些代码。谢谢。
The ASP.NET web application I am developing needs to support two different types of databases, namely Access and MS SQL Server 2008 Express.
I already have connection strings for each database type stored in web.config, and I have another web.config value that specifies which one to use. So I can get the proper connection string with no problem.
The big problem comes with the database objects. For Access, which I have already implemented, I am using the objects OleDbConnection, OleDbCommand and OleDbDataReader in the code to make the database calls.
It appears that for SQL Server, I can't use those objects, but rather I would need to use the objects SqlConnection, SqlCommand and SqlDataReader to do essentially the same things.
I want to reuse as much of my current code as possible and not have to create two separate blocks for each database type. (I have a lot of methods that take an OleDbDataReader as a parameter - I do not want to have to make 2 of each of those methods, for example.)
I noticed that the connection objects both inherit from DbConnection. And the same is true for the data readers (DbDataReader) and the commands (DbCommand).
Would it be possible to take my existing code for Access, replace all of the Ole objects with the Db objects, and then cast those objects as the proper type depending on the current database type?
Are there any best practices for supporting two database types in one ASP.NET application?
I can add some of my code if that would help. Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
是的,从框架 2.0 开始,所有数据读取器都继承自
DbDataReader
类,因此您的方法可以采用DbDataReader
而不是OleDbDataReader
,并且您可以将这些方法用于任何数据库。但是,数据库具有不同的 SQL 方言,因此您要么必须保留适用于您使用的所有数据库的狭窄功能,要么对某些任务使用单独的查询。
差异的一个具体示例是 Access 使用诸如
#2010-09-24#
之类的数据文字,而 SQL Server 使用诸如'2010-09-24'
之类的日期文字。一般来说,大多数与日期有关的内容都不同。Yes, from framework 2.0 all data readers inherit from the
DbDataReader
class, so your methods could take aDbDataReader
isntead of anOleDbDataReader
, and you could use the methods with any database.However, the databases have different dialects of SQL, so you either have to stay on a narrow path of features that work in all databases that you use, or have separate queries for some tasks.
A specific example of differences is that Access uses data literals like
#2010-09-24#
while SQL Server uses date literals like'2010-09-24'
. Generally most that has to do with dates differs.您可能缺少的链接是 DbProviderFactories 类的功能。使用此类(以及 System.Data.Common 中的相关帮助程序),您可以抽象提供程序并使用对基类(例如 DbConnection 和 DbCommand)的引用来完成工作。它看起来像这样:
提供程序名称获取起来有点棘手,但应该是与 DbProviderFactories.GetFactoryClasses() 返回的名称之一匹配的不变类名称。或者,您可以简单地对它们进行硬编码。它们变化不大,但它是嵌入代码中的神奇字符串,最终可能会导致问题。
可以通过factory.CreateCommandBuilder 访问其他功能,它可以帮助您遍历提供程序处理参数等内容的差异。
The link you're likely missing is the functionality of the DbProviderFactories class. Using this class (and associated helpers also in System.Data.Common), you can abstract the provider and use references to the base classes (such as DbConnection and DbCommand) to do the work. It'd look something like this:
The provider name is a bit tricky to acquire, but should be the invariant class name that matches one of those returned by DbProviderFactories.GetFactoryClasses(). Or, you can simply hard code them. They don't change much, but it is a magic string embedded in your code and may cause issues eventually.
Additional features can be accessed through factory.CreateCommandBuilder that can help you traverse the differences in how the providers handle things like parameters and such.