java - 通用数据库方法

Question

我有一个从 Drupal CMS 检索数据的 Java 类。 Drupal 中最终会有相当多的内容类型需要提取到 Java 和缓存中。由于 Drupal 的工作方式，每种内容类型都是一个单独的数据库 View 。

我有以下由服务层调用的方法，它返回一个特定的对象类型。但是，我担心的是针对每种内容类型的这些方法的激增。

有人可以建议一种使它更通用的方法吗？数据库方法显示在第二个代码示例中。我不知道我是否也可以使它通用，以及它是否值得。也许我可以在第一个方法中调用一个方法，让第二个方法使用 case 语句。

public DeliverySchedule getDeliverySchedule(final String cmsKey) { //     <---- make return type (Del Schedule) generic

    String cacheKey = TYPEDS + cmsKey;
    DeliverySchedule cmsInstance = CMSObjectCache.getCachedCMSObject(cacheKey, DeliverySchedule.class);   // Make generic

    // Object not found in cache, go to database.
    if (cmsInstance == null) {
        try {
            cmsInstance = getDeliveryScheduleFromDB(cmsKey);   //  <---- How can I make this generic so I can avoid DRY?
            CMSObjectCache.putCachedCMSObject(cacheKey, new CMSObject(DeliverySchedule.class, cmsInstance));
            return cmsInstance;
        } catch (EmptyResultDataAccessException e) {
            return null;
        }
    } else {
        return cmsInstance;
    }
}

数据库访问方式，具体到上面的内容类型:

    // Called from above
private List<DeliverySchedule> getDeliverySchedulesFromDB() {
    JdbcTemplate jdbcTemplate = new JdbcTemplate(dataSource);
    final String sql = "select * "
            + "         from cmsutil.delivery_schedules as m "
            + "         where m.effdate = (select max(mm.effdate) "
            + "                            from cmsutil.delivery_schedules as mm "
            + "                            where mm.cms_key = m.cms_key "
            + "                            and mm.effdate <= current_date)";


    List<DeliverySchedule> listcmsObject = jdbcTemplate.query(sql, new DeliveryScheduleMapper());
    return jdbcTemplate.query(sql, new DeliveryScheduleMapper());
}

Answer 1

通常，每个表或 View 都有一个 DAO(DAO 的接口(interface)和实现它的类)。这样，如果一个特定的表架构发生变化，您的更改将被隔离到一个 DAO 类。

您可以将内容类型概括为具有单个接口(interface)和一个为每个内容类型实现该接口(interface)的类。这应该允许您适应通用内容类型层、特定内容类型和数据访问层的变化。

我同意它可能会变成大量代码，但如果每个组件都与其他组件分离，它会在更改/添加组件或处理架构更改时为您提供灵 active 。解耦和抽象在短期内可能会很痛苦，但从长远来看往往会给整个工程团队带来返回。

我喜欢这样的问题/讨论，并且总是乐于接受建议或其他方法。