> 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.
Ok so here, UserStorage/DefaultUserStorage are here to define persistence methods for the component User/DefaultUser? (right?) 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? (this remind me a scene from MontyPython HolyGrail ;)) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
