We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.

Bug 5912 - Monograph value object contains references to DAOs
Monograph value object contains references to DAOs
Status: RESOLVED DUPLICATE of bug 5231
Product: OMP
Classification: Unclassified
Component: General
PC Linux
: P3 normal
Assigned To: PKP Support
Depends on:
  Show dependency treegraph
Reported: 2010-09-20 09:35 PDT by jerico
Modified: 2010-11-02 15:40 PDT (History)
1 user (show)

See Also:
Version Reported In:
Also Affects:


Note You need to log in before you can comment on or make changes to this bug.
Description jerico 2010-09-20 09:35:37 PDT
The signoff-related accessors in the Monograph object instantiate DAOs and access data in the database. We usually implement application objects as simple value objects and let them be populated by the DAO. So usually the DAOs populate the application objects while the application objects remain unaware of the DAO. (See the classical GoF DAO pattern).

If these fields have an important performance impact when populated or cannot be populated in all circumstances then we usually design subclasses with these accessors to be used when use-cases require the extra fields while leaving the base Monograph class alone, see the many Submission derivatives for examples.

What are the reasons for parting from the DAO pattern in Monograph?
Comment 1 jerico 2010-09-20 09:38:46 PDT
Same for getAuthors() and getPrimaryAuthor().
Comment 2 jerico 2010-09-20 10:20:27 PDT
Please also see #5913 for the author accessors.
Comment 3 Matthew Crider 2010-10-08 11:00:18 PDT
These are convenience functions, there mostly because authors used to be stored in the Monograph object as an array, but are now handled completely in the AuthorDAO (though there was really no reason to maintain backwards-compatibility there, since there is no backwards in OMP).  I'm tempted to keep these methods in the Article and Paper classes to maintain backwards-compatibility though.  Lets close this bug and continue any discussion in bug 5231.
Comment 4 jerico 2010-10-08 15:45:37 PDT
Thanks Matt, that makes sense to me. And yes, agreed, we can discuss that in 5231.
Comment 5 jerico 2010-11-02 15:40:56 PDT

*** This bug has been marked as a duplicate of bug 5231 ***