On Friday 18 May 2001 17:43, [EMAIL PROTECTED] wrote:
> > OODBMS are even implemented within the domain layer. They just store
> > the objects used by the domain layer as they are - as objects.
>
> I should like to point out that when the Next Cool Thing(tm) comes
> along objects just might stop being the most hyped things for
> implementing business logic. From which it follows that maybe
> it isn't such a good idea after all to not separate domain and
> persistence layers even with objects+OODBMS.
Hm, you might also think the other way.
Perhaps each object will bring along not only the data of its current state
but also its own userinterface? Then the domain layer would be responsible
for data storage as well as for providing a useful gui that would have to be
constructed somehow automatically (very futuristic).
Then, we would really only need to talk about servers and clients. Everything
that is needed runs on the server, even the gui. The clients would be
completely "stupid" (if I may say so) and just serve as user INTERFACE.
With JSP/Servlets it is going somehow that way, only that they are not
integrated into EJBs like EJBs already contain all mechanisms of data storage.
What I don't know is how and where to implement the workflow then,
the actual processes that would work with the objects.
Having all data (attributes) + behaviour (methods) + interface (gui)
encapsulated in the object, one doesn't have to think about horizontal layers
anymore. We could instead concentrate on the vertical domains
(different business fields such as Healthcare, Telecommunication, Transport)
and the actual logics.
This wouldn't mean that there were no more distribution. There may still be
Security/Authentication, Transaction and other servers; just that all of them
would work with our complete objects, not needing a separation into layers.
But that's all very immature and utopic. Not for our current work.
I guess we better stick to RDBMS, Karsten ;-)
--
Kind regards,
Christian
http://www.resmedicinae.org
- Information in Medicine -
