JPA entity.save (EntityManager) антишаблон

Question

Я думал реализовать антишаблон, так как @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; 
    } 

    ... 
} 

PRO:

• конкретной бизнес-логика находится внутри объекта (РЕАЛ программирование OO)
• делают использование наследования для управления бизнес-логики (другой OO шаблон)
• можно написать общий EJB

CON:

• не называется по каскадной
• контракта Дополнительно: запрещено называть em.persist(entity)/em.merge(entity)

Есть ли что-то еще я забыл?

Answer 1

CON:

• С DAO логики в объектах вы открываете ящик Пандоры. Если логика настойчивости разрешена в сущности, то почему же не логика представления? И так далее. Тогда почему же find...-методы тоже?
• Обход изоляции слоев. Если логика персистентности сосредоточена в DAO, ее легче контролировать, что делается.
• Разрыв изоляции бизнес-компонента. (Я даже не раскрываю DAO между бизнес-компонентами в моих проектах, только бизнес-сервис - на один уровень выше.)
• Перемещает фокус в сущности от моделирования бизнес-объекта до «мы просто обрабатываем некоторые данные здесь». Я сомневаюсь в цели бизнес-объекта, например, Contract - это упорство в использовании определенных технологий.