1

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

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

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

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

两个明显的选择是：

  1. 将连接键作为参数添加到所有方法。糟糕 - 不会发生，但包括完整性。

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

还有哪些其他选择？

4

1 回答 1

0

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

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

于 2011-01-22T20:25:46.287 回答