Java CRUD DAO持久化设计

Java CRUD DAO Persistence design

最近我真的专注于编写干净的代码和实现设计,但我偶然发现了一种情况,我有多种选择但无法决定哪一种是合适的。我正在开发一种需要对对象集合进行持久化的软件。我决定实施 DAO 模式。问题是持久性可以是 Json 或 Xml 所以我是这样实现的:

我创建了一个通用 DAO:

public interface GenericDao<T> {
    public boolean add(T type);
    public boolean change(T type);
    public void delete(T type);
}

然后我创建了一个CarDAO:

public interface CarDao extends GenericDao<Car> {
    public Car getByIdentificationNumber(int id);
    public void process();
}

为了JSON坚持:

JsonGenericDao:

public class JsonGenericDao<T> implements GenericDao<T>  {

    public boolean add(T type) {
        // implement ADD for json
    }
    public boolean change(T type) {
        // implement Change for json
    }

    public void delete(T type) {
        // implement Delete for json
    }
}

JsonCarDao:

public class JsonCarDao extends JsonGenericDao<Task> implements CarDao {

    public Car getByIdentificationNumber(int id) {
        // Implement logic
    }

    public void process() {
        // Logic
    }
}

JsonCarDao 扩展 JsonGenericDao 以包括添加、更改、删​​除,它还​​提供了其他方法。

同样的实现方式XmlGenericDaoXmlCarDao.

所以我最终有可能使用 XmlCarDaoJsonCarDao 取决于我想使用的持久性。

在实现持久性时,我使用 JAXB 作为 XML,使用 Gson 作为 JSON。 我做了一个 EntityCollection<T> class 来存储里面的对象,我会根据使用的持久性将这个集合转换为 XML 或 JSON,我会从中检索信息文件到这个集合,更改需要更改的内容,然后重写文件。

我有两种实现方式:

选项 1:

我可以在 JsonGenericDao 中使用 Gson 实现持久化,并在 XmlGenericDao 中对 JAXB 执行相同的操作。

选项 2:

我可以创建一个接口 Persister<T> 并编写两个实现此接口的 classes,因此 JsonPersister<T>XmlPersister<T> 具有 update(T type) 等方法和 acquireAllFromFile(),其中一个是用新数据重写整个文件,另一个是从文件中检索信息。 (同样的事情可以在选项 1 中完成,但不需要额外的 classes)

然后在JsonGenericDao<T>里面我可以使用:JsonPersister<EntityCollection<T>>XmlGenericDao<T> 里面我可以使用:XmlPersister<EntityCollection<T>> 因此打包一切。

这里的问题虽然是在考虑这个问题,但这意味着我可以摆脱 JsonGenericDaoXmlGenericDao 并实现一个 PersistenceGenericDao ,它将使用 Persister 其 CONSTRUCTOR 中的接口指定是否应使用 JsonPersister 或应使用 XmlPersister它基本上是 DAOStrategy Pattern 的组合。现在这似乎是我可以做的事情……但在我看来,它也打乱了我最初的 DAO 设计。这是正确的做法还是不好的做法?

我认为你的选项 2 实际上看起来像 GoF Bridge PatternXmlPersister/JsonPersisterConcreteImplementorPersistenceGenericDaoAbstractionJsonCarDaoRefinedAbstraction

所以这个想法实际上是有道理的。请参阅 What problems can the Bridge design pattern solve? 以检查您是否真的需要该模式。

如果您只打算使用 XML 或 JSON 持久性,我个人会选择选项 2。如果您将 JsonCarDaoXmlCarDao 进行比较,唯一的区别它们之间可能是来自某些资源的 saving/loading 数据的机制(JSON 与 XML)。其余的逻辑可能几乎相同。从这个角度来看,将 "saving/loading" 提取到特定的实现程序中并为其余的 DAO 逻辑使用一个通用的 class 是合理的。

但是,如果您考虑关系或 NoSQL 数据库持久性,这可能不太适合。因为 DAO 逻辑可能会有所不同。与 JSON DAO(从 JSON 文件加载数据并在对象集合中搜索具有给定 ID 的对象)。在这种情况下,RelationalPersistence 可能效率不高。