如果ADO的AdoConnection是直接通过赋值connectionObject获取的连接话,连接串里是没有包含密码信息的,这个时候
试图通过这个对象获取密码是徒劳的,因为connectionObject本身就已经是一个连接的,即已经通过用户+密码创建好的
连接了,这个时候理论上是不需要再保存密码了,所以这个对象里是没有密码的。
但是用这个方式获取连接的方式有一个不好的地方就是:会引起连接管理问题,需要用户自己解决;
正常来说这个connectopbject对象都是ado自己内部使用的一个对象,不建议外部直接使用(除非你特别精通ado),这
样做的好处就在于ado可以复用连接,并且ado可以自己管理连接(即什么时候释放连接),而不需用户操心这个事情;
所以即便客户端请求了5个连接,但是实际需要创建的也许只有4个或者更少,因为有连接可以复用,那么对于复用的连
接管理,就是ado自己要考虑的问题了,假设我们只是通过创建新的connection对象的话(delphi里面方法是create,.net
里面可能是new),这个时候ado是可以跟踪这个的连接的使用情况,以保证只有最后一个应用关闭了,才会释放这个
连接;
然而我们要是通过直接使用底层的connectionobject,并且我们自己把这个connectionobject分发给了不同的应用话,
那么当中有一个应用关闭连接的话,就会导致这个连接直接关闭了,导致其他的应用也没有连接可用了;所以这个时候
如果要想客户端开启的多个相同应用可以正常执行话,就需要我们自己实现连接管理,即保证这个连接只有最后一个应
用关闭后,才会被关闭,而在这之前,不论应用调用了多少次关闭连接的操作,我们实际上是不会关闭这个连接的。
否则呢?如果我们认为这个任务是实现起来比较难的,那么就要保证在一个客户端上使用这个连接对象的应用是单例
的,即在一个客户端只有一个使用这个连接的应用,这个也是我们看到为什么有的应用程序只允许一个实例运行的原
因。
因为真的没有办法,或者比较难做到,既可以使用connectionobject隐藏密码的优点,又能不用自己实现连接管理:
1、连接创建是ado做的,ado已经封装的,我们只是负责传入几个参数;
在一个客户端(workstation),相同的密码,用户,等输入的情况下,保证两个应用实例被分配的连接是两个不同
的连接(创建连接是ado做的,我们能做的就是传递连接串给ado);
2、我们使用的不是ado公开出来推荐大家使用的每次使用连接都自己创建连接的方法,而是自己封装了一个直接返回比
较底层的connectionobject来创建连接,这时ado是不会为我们做连接管理,这时就要求我们自己实现连接应用管
理,不然一个应用关闭连接了,其他的应用的连接都断了。
3、那么要怎么能,即使用connectionobject对象的看不到密码的优点,又可以避免客户端一个应用关闭连接不影响客户
端下其他相同应用呢?这个时候为了简单,索性就只允许在一个客户端只允许一个应用实例运行;(这个要比实现
连接管理简单多了))
所以总结了下,使用了一个官方不推荐的方式来使用一个对象,其潜在的问题就是:在使用这个对象时,会出现难以察觉的问题,也就是在官方推荐的时候,会特别强调,如果你不是对什么很熟悉请不要如何如何这样的提醒;