A few important patterns are used by the content beans. Keep them in mind when you write or modify content bean classes.

These patterns apply to any object that you design as a representative for data stored in an external data source and that you want to use within the data view caching framework. They ensure that the object is lightweight, interchangeable and always valid. With efficient data retrieval will be dealt at a later stage. Other designs are also possible, for example, stateful business objects are directly loaded from a DAO, but they require a more complicated interaction with the caching framework that is not covered in this manual.

Construction

Content beans are both used to denote content and references (links) to content. A content bean used as a link must be cheap to construct. Thus, at construction time, a content bean should only set the information required to identify itself: its contentBeanFactory and content object (and maybe other required services like a DAO or a JDBC data source). No content should be retrieved. The content bean source code fulfills this requirement by defining a default constructor and the two getters defined in the CoreMedia CMS interface.

Note

Content bean classes need a default constructor.

Identity, equality

Two content beans originating from the same factory for the same content object must be equal. They identify the same business identity. Content beans fulfill this requirement by inheriting #equals and #hashCode from AbstractContentBean which is defined in terms of the corresponding content methods.

Note

Content bean classes must not override equals or hashCode of AbstractContentBean.

Mutable state

A content bean must not store mutable information. Caching of mutable state is performed in other layers. All methods of a content bean should always modify the content object directly. This way, a content bean can never be invalid when the repository contents change.

Note

Content bean classes must not declare any fields except for read-only, immutable service references.

Mutable values

The results of getter methods of a content bean must not be modified by application code. Modification would lead to race conditions and break the data view framework. Getter methods of content beans should return immutable objects in order to prevent errors caused by illegal modification. In particular, they should not return arrays but immutable collections.