are you familiar with the command/commandlist patterns? these eliminate all
your concerns below.
> -----Original Message-----
> From: Andy Piper [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, May 20, 1999 4:49 AM
> To: [EMAIL PROTECTED]
> Subject: Re: sessions wrapping entities
>
<snip>
> I'll stick my head above the parapet and disagree here:)
that's the value of the list!
> If I understand
> you correctly you are talking about manipulating fine grained interfaces
> from a client,
we're doing exactly the same thing, you're just doing it (in your
own words) via fat, inflexible session interfaces and i'm using a command
structure. i also think there's an impedance mismatch regarding our view of
a client.
> this is good for you
actually, good for many but i'm unwilling to share the design other
than to say it uses Broker, Queue, CommandList, Command and some other
patterns. i'll add one additional piece of information; we tested this
structure against static, fat interfaces (as you propose) and they performed
similarly.
> because it gives you a lot of flexibility.
> However, in all large systems I have worked on fine-grained external
> interfaces are a disaster for multiple team development, because the
> possibilities for others shooting you in the foot are endless.
good design prevents this, regardless of execution implementation.
fyi: we've got people using this interface that have little to no
programming experience and we haven't seen any shootings yet ;)
> However bad it may be encapsulation-wise
agree, we don't have to break any good design rules because of our
implementation.
> fatter interfaces mean that you
> have designed the gun so the users of your interfaces can only shoot you
> in
> the way you want. Interfaces have to be dumbed down if you want other
> people to use them successfully and generally that is the case between
> client and server and server and db etc in an N-tier system. So I'm all
> for
> session wrapping.
>
> I apologise if I have misunderstood what you were saying.
no need to apologize. based on your obviously informed assertions
above, you'd understand and agree with our design if i could give you all
the details.
<snip>
===========================================================================
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".
