The Mastering Zend Framework site (from Matthew Setter) has a new post today showing you how to execute SQL queries directly in a Zend Framework v2 application.

Whilst there are many ways for building and executing SQL queries in Zend Framework 2, the two that I usually use, and which are also used in the ZF2 manual, are closures and the selectWith function. I previously wrote a three part series, showing how to get started using the ZendDbSql classes with Zend Framework 2, but I didn’t cover how to actually run them. So in today’s tutorial, let’s do that.

He gives examples of these two methods starting with closures in a "tableGateway" select call. He shows how to add on parts of the query like "wheres" and an "order by" as well as some basic formatting. He then gets into the "selectWith" examples, showing the same criteria just added a different way. He also includes an example of the "tableGateway" objects used for the examples and how they're configured.

On his MaltBlue.com blog Matthew Setter shares his opinion on TableGateways in Zend Framework v2 and wonders if they're "worth it" (as they're not the easiest thing to implement).

Are TableGateways too hard to implement in Zend Framework 2? Are they too hard to justify the effort? That’s what I was asked recently during a Twitter conversation. For me, they’re not. For me, they’re well worth the effort. So I’ve written this post to show why they’re not, and how they bring great flexibility, when implemented correctly. In [this post] I’ll set out why they can be a good solution, as well as why not.

He starts from the origins of PHP scripts, back when they were "a collection of files" and not structured under much of a framework. Complexity added the need for this structure, though, including things like design patterns for common tasks. The TableGateway was one of these. He talks briefly about implementing them in Zend Framework v2 (with some gist examples) and some questions to ask helping you determine if they're "too much" for you app.

Matthew Setter has written up a post to his site that continues his look at the features of Zend Framework 2. This time he's looking specifically at hydrators, models and the table gateways and their use in connecting your application with a database.

One set of features has really been helping me of late ones that really have me smiling; these are: Hydrators, Models and Table Gateways. If you’re new to ZF2 or database interaction with frameworks, then you’re in a perfect position as today’s post will be giving you a good introduction to the basics of using both together.

He starts with a look back at how it all was done in ZF1 and shows how using these three components makes for an even better system, allowing the model to be completely data-source agnostic. His examples start with the table gateway class, showing how to connect it with a "users" table. From there he adds in the model (with an "exchangeArray" method) and a hydrator that maps the table columns to the properties on the entity. He shows how to add this setup to the service configuration and its use in a controller, returning a full list of the records in the "user" table.

Evan Coury has a new post to his blog about using ZendDb's TableGateway (from the Zend Framework 2) along with the HydratingResultSet feature to let you build objects from your database results.

The new ZendDb in Zend Framework 2 has a handy feature which allows you to specify your own entity/model class to represent rows in your database tables. This means you can tell ZendDb to return each row as a populated instance of your own custom objects. Keep in mind that this is simply a convenience feature, and not meant to serve as a fully-featured ORM. If you’re looking for a full-blown ORM, have a look at Doctrine 2.

He includes some example SQL to create a "book" table and the ZF2 code to create the Book model, set up the database connection and generate the hydrated data set from the results. An example of doing an insert into the table and then pull it back out from the TableGateway object.