Maybe a decorator? You could then start with a base report and build it up.
$report = new ReportMetricOne(new ReportMetricTwo(new Report())); $report could then be processed by a generic reporting class/model: $reportModel->generate($report); downside = complexity, decorators can be confusing to people ala Zend_Form :) Though once you get them they are easy 2009/3/25 Cameron <[email protected]>: > Hi guys, this is probably more of a general OO question than specific to ZF, > but I thought I'd throw it out there to see if there's some really good > solutions out there. > > I've written a pretty extensive application in ZF, it's all MVC driven, uses > Dojo and AJAX, it's pretty cool, and generic and flexible enough to easily > adapt against different databases with different object relationships. I'm > pretty proud of how it's coming out so far, despite a few obvious > shortcomings, but I've gotten to the point where one of the clients using > this wants a whole lot of reports generated, and that raises issues of > architectural requirements. > > I've been looking at a Builder design pattern, but the more I think about > it, the more it doesn't really seem to solve many problems - MVC separates > the View already, and it ain't no thang to have a different view script per > report page. I guess what I'm trying to work out is how best to model the in > between bits - the classes between the View and the DB access in the Model. > > My current Models really only have the usual get / insert / list / count / > delete methods, with a bunch of private methods for filtering, sorting and > ordering the data, and so any complex report queries would need to be either > built using these tools in a separate layer, or implemented as extra methods > in the current Model classes. > > Another thing to consider is user input in these reports, like sorting by > columns, pagination, date ranges, etc. > > I guess the question is one of style and elegance. Has anyone got any > examples of a good layer between the Controller and Model(s) for reporting? > I was basically considering something like this: > > A Reports Controller with a whole lot of named Actions that map to the > various reports we'll build. > Each Action handles gentle processing of user input and passes it on to the > Reports Model. > The Reports model holds all the ugly business logic, calling queries and / > or other Models directly, processing data to a point fit to return back to > the Controller. Try and add private methods for standardizing functionality > where I can. > The regular Models mapping against the business objects remain untouched. > > My concern with this layout is one of cleanliness, I guess. It seems like a > lot of ugly code to put in the one Model. Has anyone seen this problem set > solved really nicely? Something like a handful of good generic reporting > methods that one can implement that map against a significant number of > typical reporting needs? A particular OO design pattern that suits this > really well? Something I haven't thought of? > -- ---------------------------------------------------------------------- [MuTe] ----------------------------------------------------------------------
