views:

427

answers:

1

I always come to the same problem when implementing new data object that some web site will use. It seem to me naturaly to fill the object ...

object: news
news subobjects: mediaItems, user, category

I usualy implement lazy loading of associated objects (lists of objects) and also have a static method to fill the news object data, media and category at once(from a joined sql query, as lazy loading requeres 3 queries). But sometimes, actualy quite common, I need extra parameters, for a specific view or aggregation, fetched beside the news object. To get this parameter, I would use a new sql query. At the same time I know I could have used one more complexed query to fetch the news object with this parameter included.

My question basicaly is: Do I do fetch data as a row of items and pass it to the view in the later case, or accomodate the news object with special loading and handling of the added parameter, needed only in this view and only for display.

A: 

I guess it depends on the situation. Sometimes its just darned convenient to get it along with the original query, and sometimes its not worth it - especially if the data is quite cachable.

My app uses sort of a combination - we do joins to generate multiple objects per row, and we do multiple queries to pull some other stuff back. Everything is cached via memcache though, so we're not overall worried about too many queries as long as they're all simple and quick.

We then pass along the list of rows (like list of news posts) to the view (actually a db_table_rowset), and for the other queries we just pass the individual rows (db_table_row objs). Then of course there's other vars passed to the view. The view then does the work of using the rows (the model) properly

Justin