A few important patterns are used by the generated content beans. Keep them in mind when you extend these 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 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 source code generator fulfills this requirement by generating a default constructor and the two getters defined in the CoreMedia CMS interface.

Note

When extending, you should not modify the default constructor in the generated beans.

Identity, equality

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

Note

When extending, you should not override equals or hashCode.

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

When extending, you should not declare any fields in a content bean 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.