A Dry Conversation

If not VO, then what?

Using a VO does not mean keeping state in two places. I use a VO and DAO where the DAO is a SQL, XML, or File reader and never stores state, therefore no state problems. In fact, none of the containers on the back side in my system store state. I just don't like it as a design. The only state is held in the presentation-JSP tier.

So back to my original question, if not VO, then what? Is there something better?

Mica

It sounds like to me, Kirk (and forgive me if I'm mistaken), that you aren't against the concept of a model object specifically, but what you are saying is don't duplicate that model in the EJB and outside the EJB - instead view the EJB object as a wrapper around that standard model that specifically wires in container support. Then, use the internal representation for leaving the container. This gives the added benefit of having one object to rule them all, and it can hold deterministic behavior AND data. Is that about right?

R.J. [rjlorimer@coffee-bytes.com]

R.J.

I know wish that I have said it your way :)

Mica, you are keeping state in two different places. That is what a VO is for but to hold state for an object that you can't move. Why not just move the object it'self?

Seperating state from behavior means that you will have to marry the two some time in the future. This means that you either have to move the state back into the original object (which is necessary when one uses a relation DB to persist an object), or you have to duplicate that behavior in something else. There are execeptions as you have pointed out with the JSP example. That said, frameworks that support parallel hierarchies IMHO have always been difficult to use, fragile, and difficult to maintain. Where as techniques such as serialization which do not rely on parallel hierarchies are much simplier to use,are much more robust and are very easily maintained.

Kirk,
I guess I'm pretty think-headed. I don't understand what you mean by moving the object. If I use a SQL class to get model object data, pass references to the tiers, all the while storing state data about the object in the object and only there, is that not 'moving' the object and not storing state in two places? The JSP tier stores state data in the VO thru JSP Bean references so that data is not duplicated.

Please explain moving.

Also, if you hate DTO, what do you use?

Thanks :)

Mica

Well, you do have to copy data when you move it between tiers but you still can move the domain object instead of having to transfer state and then move that object and then retransfer state into something else.