[RT] Merlin & Persistence (was: [RT] Component Persistence)

[Alexis Agahi <al...@users.sf.net>]

> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: [RT] Merlin & Persistence (was: [RT] Component Persistence)

[Stephen McConnell <mc...@apache.org>]

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.
>>    
>>
>
>
>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: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org