【问题标题】:Java CRUD DAO Persistence designJava CRUD DAO 持久化设计
【发布时间】:2018-02-18 09:48:08
【问题描述】:

最近我真正专注于编写干净的代码和实现设计,我偶然发现了一种情况,我有多种选择,但无法确定哪一种是合适的。我正在开发一个需要对对象集合进行持久性的软件。我决定实现一个 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 以包含 Add、Change、Delete,它还提供了其他方法。

XmlGenericDaoXmlCarDao的实现方式相同。

所以我最终可能会使用 XmlCarDaoJsonCarDao,具体取决于我想使用的持久性。

在实现持久化时,我对 XML 使用了JAXB,对 JSON 使用了Gson。 我创建了一个EntityCollection&lt;T&gt; 类来将对象存储在其中,我会根据所使用的持久性将此集合转换为 XML 或 JSON,我会将文件中的信息检索到此集合,更改需要更改的内容,然后重写文件。

我可以通过两种方式实现它:

选项 1:

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

选项 2:

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

然后在JsonGenericDao&lt;T&gt; 里面我可以使用:JsonPersister&lt;EntityCollection&lt;T&gt;&gt;XmlGenericDao&lt;T&gt; 里面我可以使用:XmlPersister&lt;EntityCollection&lt;T&gt;&gt; 因此打包所有东西。

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

【问题讨论】:

    标签: java design-patterns persistence dao


    【解决方案1】:

    我认为您的选项 2 实际上看起来像 GoF Bridge PatternXmlPersister/JsonPersisterConcreteImplementors。 PersistenceGenericDaoAbstractionJsonCarDaoRefinedAbstraction

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

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

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

    【讨论】:

    • 其实我打算以后用JPA。
    • @Hubbs 我认为Persister 的想法不会带来太多。
    • 所以我宁愿坚持选项 1。我在这里还缺少其他选项/设计吗?
    • @Hubbs 好吧,总有很多事情要做。但我建议不要从一开始就过度设计。实现你的JsonGenericDaoXmlGenericDaoJpaGenericDao,然后考虑是否有任何值得提取/重构的东西。可能还值得一看 Spring DAO。它使 DAO/存储库实现非常苗条。在最好的情况下,您只需编写存储库接口即可。缺点是,引擎盖下有很多黑魔法。
    • 好的,非常感谢。你在这里对我帮助很大。我真的很感激。
    猜你喜欢
    • 2011-05-21
    • 2012-08-22
    • 2013-04-03
    • 1970-01-01
    • 2016-03-17
    • 1970-01-01
    • 1970-01-01
    • 2013-08-14
    • 1970-01-01
    相关资源
    最近更新 更多