"Stephen McConnell" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > > > Alexis Agahi wrote: > > >>I'll explain below. > >> > >> > >> > >>>Should home define method that > >>>will be used by provider to establish persitence? (if yes, then > >>>this sounds nice ,)) > >>> > >>> > >>Here is a move detailed breakdown of the terms I'm using: > >> > >> * identifiable component - an instance of a identifiable component
> >> type > >> * identifiable component type - a type that includes an <indentifiable> > >> elements declaring a home interface > >> * home - a component implementing a home interface > >> * home interface - defintion of storage value creation, query > >> and destruction operations > >> * home component - a component that implements the home interface > >> and handles storage value creation query and destruction > >> using some persistence solution > >> > >>So for example, lets imagine we have something called a User and > >>that we maintain multiple users. From this we would need: > >> > >>Interfaces: > >> > >> * User - an service interface > >> * UserStorage - an interface defining operation on a user storage > >> value instance > >> * UserHome - the home interface > >> > >>Classes: > >> > >> * DefaultUser - an identifiable component > >> * DefaultUserStorage - a class implementing UserStorage using a > >> particular persistence solution > >> * DefaultUserHome - implementation of the UserHome > >> > >>A container on deploying a identifiable component would locate and > >>deploy a component implementing the UserHome service, get an > >>instance of UserStorage from the home and add this to the > >>identifiable components context. > >> > >> It seems to me like "reimplementing" CMP, if you try to persist the User like that. But what if you think at an enterprise application with 500 or more domain classes? How should navigation between those objekts should be handled in your model? Like in EJB? Reading a key for looking up an other object? Whats about inheritance? I think it's a much better approach, to persist the objects like Stephen noted below and use such a bright tool like Hibernate. I have implemented an Hibernate-Persistence-Service which deliveres the functionality through the merlin-context. All of the Hibernate interfaces are hidden, so that it should be very easy, to use just an other mapping tool too. I'll pack the code together and send it arround in the next days! Andreas > > > > > >Ok so here, UserStorage/DefaultUserStorage are here to define > >persistence > >methods for the component User/DefaultUser? (right?) > > > > Correct. > > >Dont you think compent (User/DefaultUser) could implement itself the > >appropriate method (of DefaultUserStorage) to persiste itself and > >Home/interface/Impl would find directly the appropriate component? > > > > One could do that - however - I have found that it is a good idea to > seperate the persistent object from the functional object. This enables > different types of user components that use a common persistent model. > > Cheers, Steve. > > > > >(this remind me a scene from MontyPython HolyGrail ;)) > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] For > >additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > -- > > Stephen J. McConnell > mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
