views:

28

answers:

1

I've just started using Zend Framework and Doctrine as its ORM, and I have some doubts regarding the model. It's obvious that the purpose of the ORM is just to map my domain model to database model, but I'm curious how you would model various reports needed on a Web application?

From my point of view, and correct me if I'm wrong, I should avoid writing any queries in the controller (Doctrine Query Language queries, in this case). So, if I want some arbitrary report (e.g. revenue per department, split by month), should I have a special reporting "service" in the domain? This service would fetch my report from the database using ORM queries.

If you could shed some light on this topic, I'd be grateful.

+1  A: 

For sure, sometimes DQL is insufficient. In Doctrine2 you can extend it. But Doctrine 1.x is not stupid and you can use native SQL with it: http://www.doctrine-project.org/projects/orm/1.2/docs/manual/native-sql/en

If ORM is insufficient, you can use native SQL. Reporting is the case where SQL queries become tooo complex for ANY simple QL you can image. So... I say go for native queries if you can't avoid it. But save Doctrine for everything else.

FractalizeR
Thanks. But how the model should be made? Should I have a service, e.g. ReportGenerator, with method getRevenueByDepartment()? What is the best practice regarding this?
Dario
I don't know your app structure. Having a model for "reports" is too wide interpretation of the problem. In the area I work, each report is too unique to encapsulate it into some model so I just have them as different entities. There is no reason for me they should have something in common or be actually "model". Also, reports are some kind of "read-only" models. Are they models to you at all?
FractalizeR