Swapping assemblies to implement DBMS-specific functionality

纵然是瞬间 提交于 2020-01-16 14:48:12

问题


(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


回答1:


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.




回答2:


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:

  1. Other parameters such as credentials or options can also be easily stored/passed in to the factory/activator.
  2. It's just as trivial to keep the assembly names different which is less confusing: which DAL is 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.)
  3. Can have multiple back-ends installed at once which can simplify distribution packages and testing, etc.
  4. Do not need to control the build steps as much. Do not need to to "hijack" GUIDs or all claim to be the same version.

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.



来源:https://stackoverflow.com/questions/5637729/swapping-assemblies-to-implement-dbms-specific-functionality

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!