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?
