库中静态数据需求的设计方法

时间:2013-05-21 14:45:07

标签: design-patterns

我应该设计一个可重复使用的组件。它将是一个带有API接口的Java库,隐藏所有实现细节,包括内部数据依赖性。它需要一组客户端应用程序在调用任何方法之前需要在库中配置的静态数据

经过大量辩论和讨论后,我们提出了两种设计方法

  1. 第一种设计方法:静态数据是库内部的,因此采石和数据查找表的实现应该在内部透明地实现到库的客户端应用程序

    在这种方法中,我们会做以下事项:

    A1。库内部依赖于抽象的静态数据接口,并且有各种数据源实现:例如:数据库查询实现,文件查询实现,配置查询实现
    a2。客户端应用程序使用静态数据源

    配置实现

    反对这种做法的辩论:

    D1。图书馆不应该建立数据库连接 D3。客户端绑定到数据模式,因为它无法更改查询。只有它可以将libray指向数据源

  2. 在第二种设计方法中:静态数据被视为依赖项(即使它是库的内部)。所以它应该被注入,即库的客户端应用程序需要实现所有静态数据查找

    我们会做以下事项:

    一个。 library实现了服务提供者接口(SPI)
    湾客户端应用程序需要实现接口
    C。查找表与客户端应用程序

    反对这种做法的辩论

    D1。静态数据是库的内部,库的用户不应该担心实现 D2。由于不同客户的数据大致相同,因此会有冗余代码 D3。更多冗余代码=更多错误

  3. 我不确定采用哪种方法。如果你能从你的经历中回忆起一种优雅的方法,那对我来说真的很有帮助。

    提前多多感谢!

1 个答案:

答案 0 :(得分:0)

我建议使用选项2来保持您的磁带库模块化,以便进行自己的维护。要解决让客户端自己实现数据连接逻辑的问题,请使用配置文件(例如Mapper XML以使用MyBatis进行数据库连接)运送您的库,如果用户选择更新它,则可以编辑该文件。

您可以提供其他配置选项以使用其他数据连接,但它们不必像编辑XML文件那样简单。

你可以使用默认的最简单的选项,并要求用户投入更多的工作,因为他的要求越远离默认值,同时避免将自己编码到角落里。