JPA entity.save（EntityManager）反模式

我想实现一个反模式，因为在某些情况下，

@EntityListener

s是不够的：

@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;
    }

    ...
}

赞成者：

• 特定的业务逻辑在对象内部（REALOO编程）
• 利用继承控制业务逻辑（另一种OO模式）
• 可以编写通用EJB

反对：

• 没有在cascade上调用
• 合同添加：禁止调用

  em.persist（实体）

  /

  em.merge（实体）

还有什么我忘了的吗？

CON:

• 使用实体中的DAO逻辑，您正在打开一个潘多拉盒子。如果实体中允许使用持久性逻辑，那么为什么不使用表示逻辑呢？等等那么，为什么不同时查找…-方法呢
• 绕过层隔离。如果持久性逻辑集中在DAO中，则更容易控制正在执行的操作
• 将打破业务组件隔离。（在我的项目中，我甚至不公开业务组件之间的DAO，只公开业务服务—更高一层。）
• 将实体中的焦点从建模业务对象转移到“我们只是在这里处理一些数据”。我怀疑业务对象（比如说

  Contract

  ）的目的是使用某种技术来保持自身

---

它不是仅仅扩展了

ActiveRecord

模式以包括监听器（

@PreInsert

等）之类的东西吗？我不知道这一点。是的，它是：）DAO和业务服务有什么区别？这是一个不同的问题。：）请分开问。