In a new post to his site site Joseph Silber shows you how, when using Eloquent in a Laravel application, to decouple your application from your database by removing hard-coded class names on polymorphic relationships.

Polymorphic relations let you set up a relationship between many different model types, without the need for extra tables. This works by storing the "morphable type" (explained below) in the database, in addition to the morphable type's ID.

By default, the morphable type stored in the database is the model's full class name. While this works, it tightly couples your database to your PHP application. Let's look at how we can instruct Eloquent to use more generic values for these morphable types.

He starts in with a "short refresher" on polymorphic relationships and what Eloquent models look like for a simple customer-to-address relationship. He then talks some about the "morph" type and how Eloquent stores the name of the relating model directly in the record (like AppCustomer or AppWarehouse). He shows how to customize the morph type to map the types to values in a morphMap setting to remove the need for those hard-coded class names. He wraps up the post answering the question many ask: "why doesn't Eloquent do this automatically?"

On the SitePoint PHP blog they've posted a tutorial from Christopher Vundi that looks at the relationships that are a part of the Eloquent database package in Laravel. He uses the article to re-introduce polymorphic relationships you can define between your models to make cross-entity data access easier.

You’ve probably used different types of relationships between models or database tables, like those commonly seen in Laravel: one-to-one, one-to-many, many-to-many, and has-many-through. But there’s another type of relationship that’s not so common: polymorphic. So what is a polymorphic relationship?

A polymorphic relationship is where a model can belong to more than one other model on a single association. [...] With polymorphic relationships, we don’t need two tables. Let’s look into polymorphic relationships through a practical example.

He then starts in on what he'll be making in the tutorial, a system to manage songs, albums and upvotes. He outlines the basic table structure and uses the artisan command to generate both the models and migrations for the three tables. He then runs the migration to build out the tables and starts filling in the relation methods (hasOne, belongsTo, etc) and the special "morph*" methods to define the polymorphic relationships. He includes code examples showing how to access the information from the model objects and how to create custom polymorphic types if needed.

On the SitePoint PHP blog there's a new post from Younes Rafie looking at polymorphic relationships and how they're used in the Laravel Eloquent functionality to relate tables and entities to one another.

While I was working on an application for a client, I had to implement a new module that entails the following:

• Users ask for a budget quotation for a certain task.
• Every task has a location.
• Professionals can subscribe to different zones.
• A zone can be a region or a city.

Now, let’s neglect the core application and try to implement this single module to see what we can achieve here.

He starts off by scaffolding out a basic Laravel application, setting up the database configuration and creating the migrations for "Zones", "Regions" and "Cities". He looks a bit more in-depth at how the models were created and how to create the methods relating one to another. The relation goes "through" the zones handling, so they use the "morphedByMany" and "morphedMany" to tell Eloquent how to make the connection. He then shows how to use the relations in your code and some of the collection helper methods to make it simpler to get just the data you want.

In this recent post Brandon Savage suggests that just using objects in your application doesn't mean that it's truly "object oriented development." There's other criteria that need to be met to really fit this description.

Lots of developers understand that object oriented code offers advantages over procedural programming. And so, they begin working on creating objects in their own projects, and eventually feel pretty good about what they’ve done. After all, if they’re using objects, their code must be object oriented, right? Well, not exactly.

He breaks it down into three main points that developers should consider when working with OOP in their apps: splitting responsibilities between classes, being polymorphic and using dependency injection. There's no code samples to back up the concepts here, but it's a decent list to think about. There's plenty of tutorials out there about SOLID development and dependency injection in PHP apps, so you might check some of those out to help with these concepts.