交换程序集以实现特定于 DBMS 的功能 [英] Swapping assemblies to implement DBMS-specific functionality

问题描述

(继续我的问题 此处，但认为它足以启动一个新线程)

(continuation of my question here, but thought it was different enough to start a new thread)

我想编写一个应用程序，允许最终客户使用他们首选的 DBMS(SQLServer、Oracle 等)作为后端.

I want to write an application that will allow the eventual customers to use their preferred DBMS (SQLServer, Oracle, etc) for the backend.

我可以让主应用程序调用一个位于单独程序集中的工厂"对象，该对象将返回一个特定于 DBMS 的对象，该对象实现一个包含数据库访问所需的所有调用的公共接口.然而，这意味着在每次安装时部署所有可能的 DBMS 系统的编译代码.工厂只选择配置好的组件.

I could have the main app call a "Factory" object, located in a separate assembly, that will return a DBMS-specific object that implements a common interface containing all the calls required for DB access. However, this means having the compiled code for all possible DBMS systems deployed with every installation. The factory just chooses the configured assembly.

有人可以评论这种替代方法吗?:我可以为每个使用相同命名空间的 DBMS 创建单独的程序集，例如MyDBMS，并实现相同的接口.安装时，我们只会为客户选择的 DBMS 部署程序集.通过更改构建配置，使程序集都获得相同的名称、COM ID 等，然后主应用程序就不会知道其中的区别.我已经测试过了，它似乎工作得很好.

Could someone comment on this alternative method? : I could create separate assemblies for each DBMS that all use the same namespace e.g. MyDBMS, and implement the same interface. Upon installation, we'd only deploy the assembly for the customer's chosen DBMS. By changing the build configuration so that the assemblies all get the same name, COM ID, etc. then the main app wouldn't know the difference. I've tested this and it seems to work very well.

只是想知道这样做的利弊吗?主要好处是我们可以提供额外/更新的 DBMS DLL，而无需进行任何其他重新部署.

Just wondering about the pros/cons of this? The main benefit is that we could supply additional/updated DBMS DLLs without any other redeployment.

谢谢

推荐答案

理想情况，我在您之前的帖子中建议使用类似 nHibernate 这样的 ORM 工具.在大多数情况下，数据库设计不会偏离规范太多，这会很好地工作.在一些大型应用程序上，基本上是在存储过程等方面有性能改进的应用程序，ORM 工具将开始施加限制.

Ideally, and I suggested it in passing in your previous thread, go for something like nHibernate, an ORM tool. In most situations where the database design does not deviate from the norm too much, this will work fine. On some large-scale applications, basically ones with performance improvements in things like stored procedures, ORM tools will start to impose limitations.

你可以换个角度说我只使用所有数据库通用的行为来支持多个数据库.

You could look the other way and say that I support multiple databases by only using behaviour common across them all.

ADO.NET 提供了一系列大多数主要提供商使用的接口:IDbCommand、IDbConnection、IDbTransaction.这里的缺点是您通常无法利用特定于提供商的功能或改进.

ADO.NET provides a series of interfaces that most major providers use: IDbCommand, IDbConnection, IDbTransaction. The downside here is you usually cannot take advantage of provider-specific functionality or improvements.

企业库中的数据访问应用程序块执行此操作.您可以走这条路，如果您遇到特定的需求，您可以更改 EntLib 代码以支持您的应用程序的特定要求.

The Data Access Application Block in Enterprise Library does this. You could go this route, and if you encounter the need to have something specific, you could then change the EntLib code to support your application's specific requirement.

这样，您就可以为您完成大部分逻辑.如果您随后遇到问题(可能不会)，您就可以访问源代码以解决问题.

This way, you get the bulk of the logic done for you. If you then hit problems (you might not) you then have access to the source code in order to address it.

这篇关于交换程序集以实现特定于 DBMS 的功能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！