> >This is why the session-bean-wrapping-entity-bean pattern
> >is so popular. Do not implement business logic inside your
> >entity bean. Instead, have your client perform operations
> >to the data via a session bean. The session bean can test
> >for valid data, constraints, etc. before updating the entity.
>
> I disagree. the validation he's talking about will be fine in
> an entity
> bean. Don't see any reason for putting that in a session bean
> (see earlier
> posting).
You're right. Personally, I wouldn't expose the get/set methods
to a client due to the fact they may actually use them. This would
slow the system down if they did it too much. Considering my users
are ASP writers who took one JSP class and don't know RMI from a hole
in the ground, I would suspect they would abuse the entity bean.
I prefer to have a builder create a View pattern for me which I give
to a session bean. The session bean would call the setters/getters
within the container to minimize RMI load.
My personal preference it to perform all validation in a session
bean; to me these are business rules and don't belong in the entity.
I suppose there are cases where some validation may not be considered
a business rule and placed in the entity instead.
> >The consequence of this is that entity beans have become
> >so thin, that JDO is becoming a popular (light-weight)
>
> Have you read the JDO spec? I personally find parts of it
> rather ugly,
> especially the query part. If some issues are clarified in
> the CMP2.0 spec
> I would prefer take that in an EJB environment. Apart from
> that the JDO
> spec seems to be moving on rather slowly, despite the recent
> draft but of
> course YMMV.
Haven't read Sun's JDO spec - I looked at another third party
implementation. I didn't like it, but I wouldn't rule it out
as being a good implementation. I'm talking out my ass here
so I better stop. :)
-tim
