I'm wondering what the current opinion is on having each business
object (entity bean) correspond to a stateless session bean. What I
have is a FooBean. I also have the need to create a FooDTO to send to
the client, and the need to store a FooDTO sent from the client for
storage in the database.
One solution is to have a FooDTOFactory session bean that knows how
to copy the values from the FooBean into a FooDTO, and have another
FooServices session bean that knows how to create a new FooBean and
store the values from the FooDTO. Using only local references this
gives us a total of 6 .java files and two session bean deployment
descriptors to keep track of. It also does not seem to make sense to
have a separate session bean for each use case. In fact Sun's "Core
J2EE Patterns" book mentions that as a bad practice.
In all of the other literature I've read about session beans the
general rule is to group "like functionality" into each session bean.
Wouldn't this lean towards having all of the methods that operate on a
FooBean in the same session bean? And then wouldn't it make sense to
have one method per use case on that specific session bean? So,
FooServicesLocal might look like:
public interface FooServicesLocal extends AbstractSessionBean{
public Integer getTotalBarCount(Foo f);
}
Where getTotalBarCount(Foo f) fulfills the use case "Get the total
number of Bars associated with this Foo."
Each use case that deals primarily with a Foo would mean simply
adding another method to FooServices regardless of how that use case
relates to the one above.
I'm wondering if anyone else has structured their code this way. Is
the codebase maintainable? Does it get out of hand too quickly? Is it
better than having a factory session bean and then another set of beans
to handle other functionality for that business object?
Right now we're only two developers and we have a relatively small
amount of business logic that we're implementing. But as most projects
go it will get more complicated and we'll hopefully have more
developers working on this too.
Any thoughts would be greatly appreciated.
-M@
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
