[ComponentDesignPatterns | CategoryPattern]

See ContainerIndependenceDiscussion.

----

[''Below is the original pattern and format used; currently, we're morphing it to our standard Alexanderian form.'']

'''Intent'''

Separate the aspects of managing persistence issues away from the container of components. Encapsulate the persistence or transience of a component independent of its container.

'''Motivations'''

As a component developer producing components applicable to a number of domains and to exist in an arbitrary Container, he/she cannot guarantee the level of persistence available from any particular Container/domain. To overcome this the developer would apply this pattern to guarantee the level of persistence required by their component.

Alternatively, the developer may be producing a component to be used in a specific framework, and therefore knows the level of persistence is not enough for their component. Upon applying the pattern they can be satisfied that the persistence will be sufficient.

'''Consequences'''

The ComponentManagedPersistence pattern has the following benefits and drawbacks:

1. ''It ties the component to a specific persistence store.'' This could be seen as a benefit to some developers, but on the whole a drawback as it reduces the reusability of the component. To overcome this use the ContainerManagedPersistence pattern, delegating persistence management to the components container or the PackagedPersistence pattern, which uses an
intermediary object (probably one of the GOF patterns).

2. ''Increases size and complexity of the component.'' One of the primary aims of component development is to produce small, interoperable packaged pieces of code. Having a component manage its own persistence will obviously increase its size and complexity breaking this aim.

3. ''Makes the component independent of the evolution of other components.'' This is good or bad, depending on your situation. If you want co-evolution, it is bad. But if you want to ensure that this component continues to work in the same way, regardless of its peers' evolution, then it is good (rather like RenamingWikiPages). 

This is more apparent when this pattern is used in conjunction with InheritanceManagedPersistence, where our component may have inherited its persistence management from another component or base library class.

(Maybe it should be ''Makes the component independent of the evolution of other components/containers''? Just to clarify, when you say this are you referring to removing the dependency upon another component to carry out persistence management? I suppose a container can be seen as a component. -Stuart)

'''Known Uses'''

The EnterpriseJavaBeans model has both ComponentManagedPersistence and ContainerManagedPersistence.

ADO (ActiveX Data Objects) uses ComponentManagedPersistence to read/write data to/from any kind of OLEDB provider, or using things like Orbix to get to another component model's server object, which in turn reads and writes to and from persistence. 

----
Note on the evolution of this would-be pattern: 
StuartBarker first mined this, and after seeing it complement ContainerManagedPersistence in AlistairCockburn's paragraph in InheritanceManagedPersistence, I figured it was time to whip some junk up onto WikiWikiWeb and take it from there. I copied and tweeked the Intent from ContainerManagedPersistence and felt the group could get involved, and even go as far as link it to other patterns. -- PhilipEskelin

----

One might want to look at RogerSessions ComponentOrientedMiddleware, found here : http://www.objectwatch.com/Convergence_of_TPMs_and_Components.htm

-- IngeStubdal

External Links:
* http://www.icmgworld.com/corp/developer/dev.cmp.asp
----
CategoryPersistence