支持处理 ADO.NET 数据提供程序独立代码中特定于数据提供程序的差异吗？
我有一个 ADO.NET 数据访问层，该层已编写为与多个数据提供程序一起使用，但我发现我无法使某些操作完全独立于数据提供程序。
作为我的应用程序安装功能的一部分，它告诉 DAL 创建一个包含表和一些数据的数据库。 DAL 使用 Sql 命令CREATE DATABASE。现在这对于 SQL Server 来说没问题，但是当使用 SQLite 时，不需要数据库创建步骤，因为连接字符串中指定的数据源足以定义要使用的数据库。
我目前计划通过使用虚拟 createDatabase 方法编写一个“DatabaseCreator”类来处理此问题，我可以为特定数据提供程序进行子类化，并拥有一个工厂，根据正在使用的数据提供程序提供特定的 DatabaseCreator，或者默认一。
这种方法的问题在于，我的应用程序不会“仅适用于”与创建数据库的默认方式不兼容的新数据提供程序，而是需要为新数据提供程序提供带有新 DatabaseCreator 的新版本。
我能看到的解决这个问题的唯一方法是让我的应用程序配置一个 DatabaseCreator，以类似于配置数据提供程序的方式使用，即可以在单独的程序集中提供 DatabaseCreator。
我是 ADO.NET 的新手，因此我不确定在尝试编写独立于数据提供程序的应用程序时此类问题有多常见。
ADO.NET 中是否存在对这种方法的支持？
例如，供应商提供的或第三方现有库定义了常见操作的辅助类的接口和/或实现，其实现可能依赖于数据提供程序？
或者，有更好的方法吗？
I have an ADO.NET data access layer that has been written to work with multiple data providers, and am finding that I can't make some operations completely data provider independent.
As part of my application's installation functionality, it tells the DAL to create a database with a table and some data. The DAL uses the Sql command CREATE DATABASE. Now this is fine for SQL Server, but when using SQLite, the database creation step is not required, as the data source specified in the connection string is sufficient to define the database to use.
I'm currently planning on handling this by writing a 'DatabaseCreator' class with a virtual createDatabase method, which I can subclass for specific data providers, and have a factory that serves up a specific DatabaseCreator based upon the data provider being used, or the default one.
The problem with this approach is that my app won't "just work" with new data providers that aren't compatible with the default way of creating a database, but will require a new release with a new DatabaseCreator for the new data provider.
The only way around this problem I can see would be to let my app be configured with a DatabaseCreator to use in a similar way that it is configured with a data provider, i.e. the DatabaseCreator could be provided in a separate assembly.
I'm new to ADO.NET, so I'm not sure how common this type of issue is when trying to write data provider independent applications.
Is there existing support for this kind of approach in ADO.NET?
E.g. Vendor supplied or third-party existing libraries defining interfaces and/or implementations of helper classes for common operations whose implementations may be data provider dependent?
Alternatively, is there a better way to do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 ADO.NET 中，没有定义用于创建数据库的“标准”方法。有些数据库需要 sql (CREATE DATABASE)，而有些嵌入式数据库需要特定的 API 调用来在磁盘上创建文件。所以是的，你的应用程序不能开箱即用，你是对的。
当您希望您的应用程序仅使用“新数据库”时，如果提供程序能够开箱即用地用于标准实现（可能会执行“CREATE DATABASE”语句），那么您可能会很幸运，但大多数时候您将需要提供 DatabaseCreator 的单独实现来完成数据库特定的工作。
There is no defined 'standard' way, in ADO.NET, for creating a database. Some databases require a sql (CREATE DATABASE) and some embedded database need a specific API call that creates a file on the disk. So yes, you are right about your app not working out of the box.
When you would like your application to just work with a 'new database', you could get lucky if the provider works out of the box for the standard implementation (which could be executing a 'CREATE DATABASE' statement) but most of the times you will need to provide a separate implementation of the DatabaseCreator that does the database specific work.