Seam design

[monkeyden]

I'm in the process of designing a new, and much larger Seam application and had some design questions. First, here are a few things I'd like to have in my next Seam implementation:

1. Provide some separation of interests without committing to the onerous DAO pattern
2. Provide some way to implement non-persistent business methods. These might be state-sensitive mutators (e.g. modifying some entity attribute when some other entity attribute crosses a threshold)
3. Provide a lightweight object to interact with in the SLSB, rather than the entity itself, without having to duplicate all of the entities methods.

My first thought was to have my business objects extend their respective entities, to make use of it's methods and implement finders and non-persistent business methods, but then I lose EJB 3.0 persistence, so that's out of the question.

From my first implementation of DAOs, I felt as though I was writing (generating) a lot more boilerplate code than I should. Has anyone discovered a way to get reasonable separation without having to replicate the entire entity interface?

[norman.richards]

I don't understand the motivation. The entity *IS* the lightweight object interact with at all tiers. It is a pojo with state AND behavior and happens to be able to represent data in a relational database.

[monkeyden]

I see your point, and I'm certainly starting to subscribe to this line of thinking. The only thing I'm still wondering (which may be a better question for the EJB3 forum) is if there is a way to legally implement non-persistent methods in the entity? I guess this would fall into the "behavior" category, which you mentioned. It would behave something like the @Transient annotation for methods, rather than fields as the doc states.

[norman.richards]

What is a "non-persistent method"?


Create an instance of the pojo entity class without involving an entity manager - call all the methods you want and there is no persistence involved. Set fields - it won't get written to the database. The entity manager on gets involved when you specifically ask it to. Again - the entity IS the lightweight object to interact with at all tiers.

[monkeyden]

When I say "non-persistent method" I'm referring to entity methods which don't have persistable attributes associated with them (i.e. logic only). There is surely a better way of describing it. These methods are actually related to the current state of a PERSISTED entity, so an empty pojo is of little use to them. It's really semantic state-sensitive logic. To explain, consider my other (slightly confusing) post, to which you graciously responded.

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=98505

I have an entity, which I have loaded from the EntityManager. It has an Integer attribute named status. Status can be 0 or 1. On the client I want to display "OK" for 0 and "BAD" for 1.

I'm still developing the POC for the solution but it's much simpler than I thought. I just put the "non-persistent methods" in the base class of the entity. Here is a contrived example:

public abstract class StatusBase {
 public abstract Integer getStatus();

 public String getStatusText(){
 if(getStatus().intValue() == 0){
 return "OK";
 }else{
 return "BAD";
 }
 }
}

@Entity
@Name("statusExample")
@Table(name = "MY_TABLE")
public class Status extends StatusBase implements Serializable {
 public Integer status = null;

 @Column(name = "STATUS", length = 1, nullable = false)
 public abstract Integer getStatus(){
 return this.status;
 }
}

This way I can still interact with the entity to get the non-persistent value for the view.

[norman.richards]

Yes, absolutely. Just create your methods - they really are just pojos. If the method happens to look like a JavaBean getter/setter you should mark it as @Transient so that the persistence engine won't get confused.