Marcus, Cedric:
I may be way off the mark here, but I've been working on trying to do what
sounds to me like what you're describing: I've been developing a package to
encapsulate logic in a way similar to a session EJB, but with a distinct
leaning towards a finite-state machine model. I've created a generic way to
represent inputs, outputs, and actions that imply nothing about their
presentation, and have encapsulated the state object seperately from the
finite-state model itself. I guess I've been trying to acheive a complete
MVC model that can scale both up (with EJB's implementing the states) and
down (without EJB's, in a simple J2SE environment).
The package itself is part of Expresso, an opensource web app framework. I'd
be very happy for any comments, input, criticisms, etc!
Mike
JCorporate Ltd
http://www.javacorporate.com
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Marcus Ahnve
Sent: Saturday, March 18, 2000 9:15 AM
To: [EMAIL PROTECTED]
Subject: Re: EJB and ODBMS
Cedric Beust wrote:
*snip*
> - MVC. I still have to see a real-world MVC where the three units are
totally
> unaware of any private parts
A true MVC implementation is hard to find - I agree, and I do come from
Smalltalk
myself. On the other hand today we have Swing which is sort of (M)-(VC) and
at
least by keeping the model separated from the view we get the robustness we
need
in GUI programming. I would like to see some sort of parallell thing in
EJB, be
it some sort of Model - Resource pattern where the Resource is detached from
the
model, not indicating what we have in the back.
> The pattern here seems to be a separating entity that provides a certain
amount
> of separation but still needs to know a little bit about the two worlds it
is
> trying to connect.
Of course - the model needs to fulfill its responsibilities towards the
resources.
Some sort of name standard like the JavaBeans would be nice.
> Entity beans seem to fit nicely in this role.
I have to disagree, in my opinion they show way too much resource
information. Of
course you can tweak Entity Beans into doing what you want it to do, but
IMHO it
is the old case of violently pushing the square thing through the circular
hole.
> The technology
> is still young, explaining why they are maybe too much aware of both the
model
> and its user, but as time goes by, I expect the abstraction to become
stronger,
> although we will probably never reach a complete clean-cut abstraction.
> The important is not so much the complexity of the barrier, but the ease
with
> which we can replace it with something simpler as progress is made.
I was just about to write something in the same spirit of that but I'll just
agree- well said! ;-)
Regards
Marcus Ahnve
Sun Java Center
Sweden
===========================================================================
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".
