Hi Derek,
On May 17, 2005, at 12:11 AM, Derek Rendall wrote:
> I get the impresssion that the m-tier is only concerned with the
> splitting of the data layer tier (i.e. the cayenne bits).
Yes, that's the main goal.
> What about the ability to support other server side logic (say some
> ejb's, SOA based components or just some "sensitive" stuff that should
> NEVER be passed to client to look after)?
We are not in business of replacing web services, RMI and such, however
I am planning to add support for executing server-side business methods
from the client "peer" objects.
> By the looks of it I suppose the command pattern could be extended to
> incluse some more "commands"? However, I feel that it might become bit
> unwieldy for cases where there is a lot of server commands? If that's
> the path to take, what about a pluggable command architecture?
I got hooked on the visitor pattern recently. It really helps in
building an extendable matrix of command/operand combinations. But you
are right - if we get too many commands, it will become unmaintainable.
My goal was to keep the basic inter-tier communication "language" very
simple and limited to just a few commands. I guess once all the main
Cayenne features get fully implemented in the client tier, it will be
more clear whether this works or not.
Also as ClientCommand does its own dispatching, it should be possible
to implement custom ClientCommand/ClientCommandHandler pairs that use
the same communication channel, but extend standard basic inter-tier
"language". I guess we may even provide an explicit extension point in
the handler ["executeUnknownCommand(ClientCommand)" or something].
Andrus
This archive was generated by hypermail 2.0.0 : Tue May 17 2005 - 21:33:39 EDT