交换程序集以实现特定于 DBMS 的功能
（我的问题的延续此处，但认为它的不同足以启动一个新线程）
我想编写一个应用程序，允许最终客户使用他们首选的 DBMS（SQLServer、Oracle 等）作为后端。
我可以让主应用程序调用位于单独程序集中的“Factory”对象，该对象将返回一个特定于 DBMS 的对象，该对象实现一个公共接口，其中包含数据库访问所需的所有调用。然而，这意味着每次安装时都会部署所有可能的 DBMS 系统的编译代码。工厂只是选择配置好的组件。
有人可以评论这种替代方法吗？ ：我可以为每个使用相同命名空间（例如 MyDBMS）的 DBMS 创建单独的程序集，并实现相同的接口。安装后，我们只会为客户选择的 DBMS 部署程序集。通过更改构建配置，使程序集都具有相同的名称、COM ID 等，然后主应用程序将不会知道其中的差异。我已经测试过这个，它似乎工作得很好。
只是想知道这样做的优点/缺点吗？主要好处是我们可以提供额外/更新的 DBMS DLL，而无需任何其他重新部署。
谢谢
(continuation of my question here, but thought it was different enough to start a new thread)
I want to write an application that will allow the eventual customers to use their preferred DBMS (SQLServer, Oracle, etc) for the backend.
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.
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.
Just wondering about the pros/cons of this? The main benefit is that we could supply additional/updated DBMS DLLs without any other redeployment.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
理想情况，我在之前的帖子中建议，选择像 nHibernate 这样的 ORM 工具。在大多数情况下，数据库设计不会偏离规范太多，这样就可以正常工作。在一些大型应用程序中，基本上是在存储过程等方面具有性能改进的应用程序，ORM 工具将开始施加限制。
您可能会以另一种方式看待并说我通过仅使用所有数据库中通用的行为来支持多个数据库。
ADO.NET 提供了大多数主要提供商使用的一系列接口：
IDbCommand、IDbConnection、IDbTransaction。这里的缺点是您通常无法利用提供商特定的功能或改进。企业库中的数据访问应用程序块可以执行此操作。您可以走这条路线，如果您需要特定的东西，您可以更改 EntLib 代码以支持您的应用程序的特定要求。
这样，您就可以完成大部分逻辑。如果您随后遇到问题（可能不会），您就可以访问源代码来解决它。
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 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.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 驱动程序（例如 ADO.NET 中的驱动程序）的工作方式（除非它们具有不同的名称/程序集，但共享相同的接口/契约）。
如果在配置上使用交换程序集，那么这是完成配置的交易（例如，文件系统与配置条目）。有一些事情需要考虑，例如强名称和显式版本。
我不能证明只交换程序集是合理的，并且需要配置条目（而不是交换）的一些优点是：
thedall.dll？ （如果版本等相同，唯一要做的就是一些校验和或反编译或“信息”方法。不是很有趣。）我过去使用过的一个工具是 iBATIS，并且有 iBATIS.NET。它与 Hibernate 或 Active Record 等不属于同一“ORM 类”，因为它是定义的 SQL 语句和对象之间的简单映射器。非常原始，是的。需要大量 SQL，是的。但有些人对此发誓。
快乐编码。
Yes, it's possible: this is how DBMS drivers -- such as those in ADO.NET -- work (except they have different names/assemblies while sharing the same interface/contract).
If swapping assemblies are used over a configuration then it is a trade where the configuration is done (file-system vs. configuration entry, for instance). There are some things that need to be considered such as strong-names and explicit versions.
I can not justify just swapping the assembly and some advantages for requiring the configuration entry (instead of swapping) are:
thedall.dll? (If the version, etc, are the same, the only thing to go on is some check-sum or de-compilation or 'info' method. Not very fun.)One tool I have used in the past is iBATIS and there is iBATIS.NET. It is not in the same "ORM class" as Hibernate or Active Record, etc, as it is a simple mapper between defined SQL statements and objects. Very primitive, yes. Requires lots of SQL, yes. But some people swear by it.
Happy coding.