将现有项目与外部开源jars解耦的实践/策略

Question

我的系统通过Hibernate/JDBC连接到Oracle。我想使用抽象来重构它，以将其实现与Hibernate库解耦。这是一个备份，因为有一天团队可以切换到另一个JPA实现，而不会痛苦地将核心业务逻辑更改为具有新JPA实现的适配器。这样做有什么建议吗？

顺便说一下，我想从大师那里得到一些建议，将现有项目从外部开源jars中分离出来的常见做法/策略是什么？

Answer 1

直接依赖于标准的和流行的开源库是可以的。你不应该认为这是一个问题。例如，我有一个很大的代码库，它依赖于joda-time，google-guava等等。

1. 您从一个JPA实现迁移到另一个实现的机会非常小，因为当您熟悉一个特定的实现时(是的，因为您可能想要优化某些实现，或者您正在寻找标准JPA中缺少的某些功能)，这将需要一些时间，并且您真的不想花费相同的精力来学习其他实现(即使您想，业务也不会让您；-)。
2. Spring已经抽象了大多数常用的API，如JPA、JMS等，所以我建议您考虑一下该选项。

Answer 2

你应该使用program against interfaces来减少依赖。包含业务逻辑的服务类-the应该依赖于数据访问对象接口，而不是特定的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

Answer 3

JPA已经是一个独立的API。如果您的团队使用JPA，那么您应该已经具备了从hibernate轻松切换的能力。