Question

我正在考虑实施反模式，因为@EntityListener在某些情况下是不够的：

@MappedSuperclass
public abstract class AbstractEntity implements Serializable
{
    ...

    public abstract AbstractEntity save(EntityManager em);

    ...
}

@Entity
public class ConcreteEntity extends AbstractEntity
{
    ...

    public ConcreteEntity save(EntityManager em)
    {
        doSomeStuff(this);

        ConcreteEntity merged;
        if(id == null)
        {
            em.persist(this);
            merged = this;
        }
        else
        {
            merged = em.merge(this);
        }

        doOtherStuff(merged);

        return merged;
    }

    ...
}

PRO：

特定业务逻辑位于Object（ REAL OO编程）
利用继承来控制业务逻辑（另一种OO模式）
可以编写通用EJB

CON：

没有在级联上调用
合同添加：禁止致电em.persist(entity) / em.merge(entity)

还有别的我忘了吗？

Answer 1

CON：

在实体中使用DAO逻辑，您将打开潘多拉盒子。如果实体中允许持久化逻辑，那么为什么表示逻辑也不行呢？等等。那么，为什么不find... - 方法呢？
旁路层隔离。如果持久性逻辑集中在DAO中，则更容易控制，正在做什么。
将打破业务组件隔离。（我甚至不会在我的项目中的业务组件之间公开DAO，只有业务服务 - 高一层。）
将实体中的焦点从建模业务对象移动到＆＃34;我们只是在这里处理一些数据＆＃34;。我怀疑业务对象的目的，比如说Contract是使用某种技术来坚持自己。

JPA entity.save（EntityManager）反模式

1 个答案: