Composite entity pattern: Difference between revisions

Revision as of 14:55, 12 February 2016

Revision as of 02:40, 18 March 2016

Line 16:

==Consequences==

According to Oracle description of the pattern, consequences includesinclude eliminating inter-entity relationships, improving manageability by reducing entity beans, improving network performance, reducing database schema dependency, incresingincreasing object granularity, facicilitatingfacilitating composite transfer object creation and overhead of multi-level dependent object graphesgraphs.<ref name=":o_cjp"/>

===Drawbacks===

The fatal drawback is the requirement of bean-managed persistent (BMP) [[JavaBeans|bean]]. This involves more work for developers, and craetecreate some problems as follows:

* materializing all the data in a coarse-grained entity whenever it is accessed, is unacceptably expensive

* In [[Java (programming language)|Java]], implementation of the ejbStore() method needs to be smart enough to avoid issuing all the updates required to persist the entire state of the object, unless the data has changed in all the persistent objects.