调用者决定数据连接的策略

Question

考虑一个现有的数据访问和业务逻辑层，它被多个不同的应用程序使用，并且到目前为止，在使用它的任何给定应用程序的生命周期内只需要一个数据连接 - 因此可以简单地提取连接信息通过应用程序配置文件中的数据层。然而，展望未来，数据和逻辑类需要为应用程序提供灵活性，以便在每次调用的基础上确定数据连接。更重要的是，这些类现在被多个应用程序通过服务同时调用。

调用者不想专门管理连接字符串，而是希望以枚举形式的连接名称可以解析为数据层中的连接字符串。

目前，所有数据和逻辑类都是静态的，数据范围为内部，逻辑范围为公共。

考虑到 API 可用性、性能、线程安全/调用者隔离等因素，有哪些好的策略可以从调用者获取密钥一直到数据类中的方法。

两个明显的选择是：

1. 将连接密钥作为参数添加到所有方法。糟糕 - 不会发生，但为了完整起见。

2. 将逻辑和数据类更改为实例类，并在构造函数中传递密钥以供任何成员方法使用。不会有任何方法签名更改，而是对 API 的调用方式进行重大更改。

还有哪些其他选择？

Answer 1

不幸的是，您找到了处理此类问题的两个最佳选项。 ＃2通过涉及服务变得更加复杂，因为不同的服务请求要么需要一种方法来记住哪个客户端是哪个（如会话），要么必须在每次调用时通过服务传递连接信息。

我认为，如果您创建一个客户端包装类来访问该服务，您可以限制您需要进行多少客户端更改。对于服务本身，我认为您真的会因为每次都将连接作为参数传递而陷入困境，因为那里的替代方案非常复杂。