将现有项目与外部开源 jar 解耦的实践/策略 [关闭]答案

【问题标题】：Practices/tactics to decouple existing projects from external open source jars [closed]将现有项目与外部开源 jar 解耦的实践/策略 [关闭]
【发布时间】：2012-03-02 02:47:31
【问题描述】：

我的系统正在通过 Hibernate/JDBC 连接到 Oracle。我想使用抽象对其进行重构，以将其实现与 Hibernate 库分离。这是有朝一日团队可以切换到另一个 JPA 实现的备份，而无需痛苦地更改核心业务逻辑以适应新的 JPA 实现。这样做有什么建议？

顺便问一下，我想从大师那里得到一些建议，将现有项目与外部开源 jar 解耦的常见做法/策略是什么？

【问题讨论】：

标签： java design-patterns architecture open-source

【解决方案1】：

直接依赖标准和流行的开源库是可以的。你不应该认为这是一个问题。例如，我有一个庞大的代码库，它取决于 joda-time、google-guava 等。现在，针对您的情况，以下是我的观点

您从一个 JPA 实现迁移到另一个 JPA 实现的可能性非常小，因为当您熟悉特定实现时（是的实现，因为您可能想要优化某些东西，或者您正在寻找一些功能标准 JPA api 中缺少）这将需要一些时间，而且您真的不想花费同样的精力来学习其他实现（即使您愿意，企业也不会让您这样做 ;-)）。
Spring 已经抽象了大部分常用的 API，如 JPA、JMS 等，所以我建议你看看这个选项。

【讨论】：

Google-guava 是一个很棒的一体化库。谢谢你让我知道。正如您所确认的，直接依赖通常是可以的。然而，我们偶尔需要一个抽象。例如，目前我们使用的是缓存库，但它未来会出现一个新的性能强大的缓存库。然后松散耦合发挥作用。

【解决方案2】：

你应该program against interfaces 来减少依赖。您的服务类（包含业务逻辑的服务类）应该依赖于数据访问对象接口，而不是特定的 DAO 实现。像这样的：

public class ImAServiceBean {

    private EntityDAO entityDAO;

    private void someBusinessLogic(){
        entityDAO.createInstance(...);

DAO 接口是这样的吗：

 public interface EntityDAO {

    void createInstance (...);
    void updateInstance(...);

现在您正在使用 EntityHibernateDaoImpl 之类的东西，但是如果您想将持久性框架更改为 MyBatis，您可以构建一个 EntityMyBatisDaoImpl（它实现 EntityDAO）并在您的服务类中使用该类，而无需任何更改（假设您重新使用某种依赖注入）。如果您使用 JPA、JDO 或任何持久性技术，同样的事情：您的业务逻辑只依赖于一个普通接口，该接口可以实现，但任何持久性技术，甚至 JDBC 都可以实现

【讨论】：

谢谢。您能否展示一些您用来与外部库（瓦片、轴、显示标签..）解耦的最常见的设计模式（例如包装器、适配器、桥接器......）（对不起，如果这个问题如此笼统）
你能说得具体一点吗？困扰你的依赖是什么，在什么情况下？发布的答案是针对接口进行编程的示例：en.wikipedia.org/wiki/…
不要忘记 DAO API 和实现应该在单独的库中，只有这样解耦才会完整。

【解决方案3】：

JPA 已经是一个单独的 API。如果您的团队使用 JPA，那么您应该已经能够零努力地从休眠状态切换。

【讨论】：