Chip,
This isn't exactly an answer to your specific problem, but shows in general
how we approach this part of the problem space.
In our best practices work, we have identified a design pattern we call
"Three Levels of Domain Interface". The three levels are Idenity, State and
Behavior interfaces. On the server, our domain objects implement all three
(Identity is the root, State inherits from Identity and Behavior inheris
from state). Identity represents only the identity of the domain object.
State provides getters/setters but know deep semantic domain behavior.
Behavior contains additional behavior that is only on the server side.
So when we pass a domain object by value to the client, we pass Identity or
State instances (depending on use case). The return types and arguments on
the service layer (which are Session Beans) are typed to these interfaces.
I believe there is some re-factoring going on in this area, but the basic
concept is holding up I think.
So get/set behavior is duplicated on client "copy/view" objects, but
"behavior" interface is not dupllicated. Code generation tools could
automate the creation of the simple State objects... Strong typing is a pain
in the butt when it comes to distributing domain object state. In Smalltalk
we could have generic proxies that "became" the target object as state was
replicate during object graph traversal. Java is progress? Oops, showed my
colors ;-)
Regards,
-Chris.
> -----Original Message-----
> From: WHITESIDE, CHIP [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, December 15, 1999 4:44 PM
> To: [EMAIL PROTECTED]
> Subject: Newbie question re: bean design
>
> I am beginning to design EJBs, and have come across an issue with how to
> design them. For example, we have many different type of addresses
> (Client,
> Contact, Company, etc), and so I have created an Address bean that gets
> and
> sets the Address no matter what type it is passed. When I get to the
> Client, though, I am thinking about creating a Client bean, that has
> methods
> to get and set the name, status, etc. However, using the same model as I
> did with the Address, it makes more sense to create a Name bean, to get
> and
> set Names (Client, Contact, Company, etc). I see benefits to both sides.
> The Name bean gives me much greater re-use of code, but seems to be too
> low
> a level of granularity. However, if I place it at the Client level, then
> I
> am duplicating code left and right. I could have the methods in the
> Client
> call a Name bean, but that seems to be too much overhead. Would someone
> provide suggestions on how they handle this, or point me to a resource on
> the Web?
>
> Thanks,
>
> Chip Whiteside
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
