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.

I previously talked about the terms I use for objects in the model layer and now it's time to put some code on those bones. Note that,as always, all code here is example code and not production-ready.

He includes sample classes related to his "books" examples - a "book" entity (with title, author, id and ISBN), a mapper object to load/save/delete the entity and a service object that provides an interface for the entity to the rest of the application.

I currently use a very simple set of core objects within my model layer: entities, mappers and service objects. [...] I dislike the phrase "service object" as the word "service" means so many things to so many people. I haven't heard a better phrase yet that everyone understands though.

He defines each of the types of objects to help make the separation clearer. Here they are in brief:

• Entities are objects that represent something in my business logic.
• Mappers know how to save and load an entity from the data store.
• Service objects provide the API that the rest of the application uses.

Some of the comments on the post relate his choices to use in Zend Framework v2-based applications, noting that there are some base components you can extend to create these kinds of objects.

Welcome to part 2 of this two-part series discussing MVC and PHP, where we'll discuss some of the considerations one must make when using an MVC architecture. If you've come straight to this article without reading part 1 first, I encourage you to head back and have careful read as this one will assume that you've read and understand everything it discussed.

He talks about some of the things more involved in making a MVC framework including routing and URL formats and working with templates. Sample code is included for the route handling, model/controller relationship and view classes for the templates.

The Model-View-Control (MVC) pattern, originally formulated in the late 1970s, is a software architecture pattern built on the basis of keeping the presentation of data separate from the methods that interact with the data. In theory, a well-developed MVC system should allow a front-end developer and a back-end developer to work on the same system without interfering, sharing, or editing files either party is working on. [...] In this article, I will go the basic principles of MVC, a run through the definition of the pattern and a quick example of MVC in PHP. This is definitely a read for anyone who has never coding with MVC before or those wanting to brush up on previous MVC development skills.

He starts with an introduction of the overall structure of the pattern, how each part talks with the others. He then talks about each piece in a bit more detail and provides some code examples for some very basic MVC classes. There's no routing or anything connected to them like there would be in a framework - it's just the classes taking the others in as parameters.

RESTful APIs have been an interest of mine for a couple of years, but due to circumstances, I've not had much chance to work with them in any meaningful fashion until recently. Rob Allen and I proposed a workshop for PHP Benelux 2013 covering RESTful APIs with ZF2. When it was accepted, it gave me the perfect opportunity to dive in and start putting the various pieces together.

After going over the "Richardson Maturity Model" for the REST structure he spends the rest of the post looking at HAL ("Hypertext Application Language") structure and examples. He mentions the media types it uses, how it handles links between resources and how to embed a resource into the resulting response.

Today I want to provide a tutorial on how to do some basic interaction with a database in Lithium, and I am going to rely on MySQL as a database for the purposes of this tutorial, although you have other options like MongoDB, as an example.

His example script uses the idea of "blog posts" stored in a MySQL table and code snippets are included showing how to:

• Create the model class based off of the core Lithium one
• Select all of the records from the table
• Filter down the returned values with "magic finder" methods (like "findAllByStatus")

You can find out more about the framework in the project's documentation section of their site.

Sencha Touch models have the ability to work with a proxy. This feature allows you to save and retrieve model data from the server, memory or local storage, without depending on a Sencha Touch data store. Let's try it with a very simple scenario where the server side is a PHP page.

The article includes both the Javascript to create the models (along with its proxy and custom API methods defined) as well as the PHP that powers the backend. The PHP just reads from the "php://input" stream and echoes back out JSON, but it gives you an idea of what to expect to receive. For more information on Sencha Touch, check out their documentation.

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.

In this Nettuts+ mini-series, we'll build a web application from scratch, while diving into a great new PHP framework that's rapidly picking up steam, called Laravel. In this lesson, we'll be working on an integral part of any web application: the Models. Along the way, we'll learn about Laravel's amazing ORM implementation: Eloquent.

The tutorial introduces you to the concept of "Models" and some of the conventions that surround them in the Laravel framework. They show some of the most common operations (CRUD) and how to define relationships between the models (has many, has one, etc). They apply this to their "Instapics" example application, creating the interfaces for the users, profiles, relationships, photos and comments. They include the code to create the controllers/views to go along with them, making a simple interface to show users and their photos.

You can find out more about the Eloquent ORM in this section of the Laravel manual.