Content deleted Content added
Shevonsilva (talk | contribs) No edit summary |
Shevonsilva (talk | contribs) No edit summary |
||
Line 12:
According to Oracle description of the pattern, consequences includes eliminating inter-entity relationships, improving manageability by reducing entity beans, improving network performance, reducing database schema dependency, incresing object granularity, facicilitating composite transfer object creation and overhead of multi-level dependent object graphes.<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 craete some problems as follows:
* materializing all the data in a coarse-grained entity whenever it's 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.
Composite entity pattern can only be implemented using BMP or by adding more hand-coded persistence logic to comtainer managed persistance (CMP) [[JavaBeans|beans]]. These both approaches reduce the maintainability.<ref name=":eojdad">{{Cite book|title = Expert One-on-One J2EE Design and Development|last = Johnson|first = R. |publisher = Wiley Publishing, Inc|year = 2003|___location = Indianapolis|volume = |pages = 290}}</ref>
==Sample code==
|