• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 301
  • Last Modified:

Zend Framework - loading data at startup


I am new to Zend and am trying to learn what are the best practices.
One of the things I am doing is loading all the menu items from the database - that will be shown in all the pages of the website.

Now instead of pulling the items everytime - I want to pull the items once and store them in the session or namespace and just read it from the session and display it everytime the page is accessed.

At which place am I supposed to load this data from DB and store in session. Should this be done in bootstrap.php - It cant be done in the main index controller as a user might now always come from the main page.

So it advisable to load such things in the bootstrap.php or how else is it done.

  • 2
1 Solution

Session is supposed to store per-user variables (like login state) not menu items that'll be same for all users. In fact you should limit session data, by limit i mean not making 1092 copies of same "thing", just to show it later.

All you'll do is slowing everything down. mySQL have its own cache, so there's no need to keep static queries in additional cache if they're as simple as fetching a couple of menu items.
gubloooAuthor Commented:
I agree but are you recommending that I pull these menu items from the database every time a page is requested. In Zend that would mean, every controller should be fetching these menu items. Somehow that doesn't sound right.

Like for example the database connection is setup once and stored in the Zend::Registry in the bootstrap.php file.

Can't we do something like that here.
> In Zend that would mean, every controller should be fetching these menu items.
> Somehow that doesn't sound right.

Yes you're right it doesn't sound good, too.

I'm not using Zend FW professionally, however i can tell you how it's done in handshakes pro and other scripts that implements some aspects of MVC:
+template (for main menus)
+method/tasks assigned to specific view + template (for other menus)

Eg. for main menus we just use template that's added as the last step of generating the output. For sub-menus we assign template + method to specific view, or just include a menu  template in view's main one.

Eg. you have http://site.com - there's one main menu, but after you login - task list in the form of module->method is loaded from the DB and also "account panel" menu is included based on DB assignment info.

That should help for MVC, .ASP/MVC menu should work same way, only the function names will be different.

For me i'd just load template and fill it with content in the MVC dispatcher, skipping MVC architecture, and maybe skipping DB, too. Actually querying DB each time the page is reloaded will have no real performance impact because 1. data is static -> so 2. there will be no "real" query, the server will just  take the result from cache.

I think it's too much of a hassle to use MVC for a menu, but that's only my opinion :)

>Like for example the database connection is setup once and stored in the Zend::Registry in the >bootstrap.php file.

Zend registry is just a prettier name for $GLOBALS variable (AFAIK). Now for the DB connection: it's made every time you refersh the browser page. Same for session data, it's re-read each time you open the page, and saved each time the script updates the session data. The reson you may think it's done "automatically" and have no performance impact is that the framework/php does it for you.

The menu need to be loaded "from somewhere". Fetching it from DB each time the page reloads is actually nearly the best solution in spite of speed.

Other option would be:
+ using a template + skipping DB (fastest).
+ template + DB (slower, but very little)
+ Caching DB output in some file on memcached (slow, and error prone using file caches)

You can use session and it's worst case you can make. Because all previous solutions are based on reading from files/db and writing to files. 1 and 2 is fast, because there are no writes. 3 is slow.

Session mechanism is often implemented on database backend. And writing to db is very slow + it invalidates the query cache. But DB sessions are very helpful when you have to scale the script to several servers. DB writes are a performance killer that should be avoided at all costs, BUT in most cases you'll only need to keep logged users login/password in session data so DBs are suitable (many reads, almost no writes).

So writing redundant data to session is an excellent example of writing some caching code that'll only slow everything down and will make the script impossible to scale. As I said i don't develop in MVC professionally (I professionally optimize scripts however), maybe buying a book on MVC use cases is best thing to start.

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now