在我们的遗留Java EE应用程序中,有许多值对象(VO)类,它们通常只包含getter和setter,也许equals()和hashCode().这些(通常)是要在持久性存储中保存的实体.(为了记录,我们的应用程序没有EJB - 尽管未来可能会发生变化 - 我们使用Hibernate来持久保存我们的实体.)操作VO中数据的所有业务逻辑都在不同的类中(不是EJB,只是POJO) ).我的OO心态讨厌这个,因为我确实认为给定类的操作应该驻留在同一个类中.所以我强烈要求重构将逻辑转移到相关的VO中.
我刚刚与一位在Java EE方面比我更有经验的同事进行了讨论,并且他证实了愚蠢的实体至少曾经是推荐的方式.不过,他最近也阅读了有关这一立场有效性的意见.
我知道有些问题至少限制了实体类中的内容:
有没有更合理的理由不将逻辑移入我的实体？还是要考虑其他任何问题？
这是一个相当冗长(并不过于复杂)的设计问题,所以请耐心等待.我正在尝试使用POJO和JPA实现人员/角色管理系统.我是ORM的新手,这主要是一个映射问题.
我已经将它作为POJO工作,并且对调用者级API感到满意,但现在想在Seam环境中使用JPA或Hibernate将其映射到数据库.
我的实现基于Decorator(GoF)和Person Role Object模式(Baumer/Riehle等人).所有角色都是硬编码的,并且不支持运行时添加新角色,因为它需要更改代码以扩展行为.我将使用用户组来实现安全性和权限.
有一个Person接口,其中包含角色管理方法,如addRole(),removeRole(),hasRole(),getRole(),getRoles()等.具体实现由PersonImpl类提供.
有一个抽象类Role,它还实现了Person接口(用于装饰器替换等价),以及一个扩展它的RoleImpl类.Role类包含对person实例的引用,使用它来为person接口上的任何方法/属性调用提供服务,这意味着Role的所有子类都可以处理Person接口.角色构造函数将person对象作为参数.
这些是接口/类:
public interface Person {
public String getFirstName();
public void setFirstName(String firstName);
.
.
.
public boolean isEnabled();
public void setEnabled(boolean enabled);
public Set<Role> getRoles();
public Role addRole(Class<? extends Role> roleType);
public void removeRole(Class<? extends Role> roleType);
public boolean hasRole(Class<? extends Role> roleType);
public Role getRole(Class<? extends Role> roleType);
public enum Gender {MALE, FEMALE, UNKNOWN};
}
public class PersonImpl implements Person {
.
.
.
}
public abstract class Role implements Person { …我真的很喜欢JBoss Seam应用程序框架.由于JSF/EJB/JPA之间的注入/拒绝和紧密集成的概念在Java应用程序框架中相对稀少,因此我一直在寻找一些用于设计模式和使用此框架的最佳实践的良好资源.我已经倾注了关于这个主题的例子和几本书.但是,我对与传统J2EE设计模式相比的实际设计模式更感兴趣.例如,传统DAO与EntityHome/EntityQuery.业务逻辑应该在哪里执行？在Action类中？还是在专门的服务类？我非常感谢Seam开发人员可以提供的任何经验.谢谢!