PKP Bugzilla – Full Text Bug Listing
|Summary:||Monograph value object contains references to DAOs|
|Component:||General||Assignee:||PKP Support <pkp-support>|
|Version Reported In:||Also Affects:|
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.