Laravel Model events allow you to tap into various points in a model’s lifecycle, and can even prevent a save or delete from happening. The Laravel model events documentation outlines how you can hook into these events with event classes, but this article aims to build upon and fill in a few additional details on setting up events and listeners.

The article starts with an overview of the different types of events available on the models and a brief summary of when each are fired. It then walks you through the process of registering events and where to configure the event-to-handler relationship. The artisan make:event command can then generate the skeleton code for you. In this class you can then add the handler method and then configure it in the providers. Finally it shows an example of how to test the event, stopping the save event and using observers to group the event handling.

On the TutsPlus.com site they've posted a tutorial for the Laravel users (well, Eloquent users) out there showing the use of mutators and accessors in this ORM package.

In this article, we'll go through mutators and accessors of the Eloquent ORM in the Laravel web framework. After the introduction, we'll go through a handful of examples to understand these concepts.

In Laravel, mutators and accessors allow you to alter data before it's saved to and fetched from a database. To be specific, the mutator allows you to alter data before it's saved to a database. On the other hand, the accessor allows you to alter data after it's fetched from a database. In fact, the Laravel model is the central place where you can create mutator and accessor methods. And of course, it's nice to have all your modifications in a single place rather than scattered over different places.

The tutorial starts with the creation of a simple "Post" model to use in the examples via the artisan command. It also includes the full code to flesh out the class to define a mutator and accessor for the "name" property. It then talks through what these two methods do and how they're called automatically when the property is accessed/updated. It's then put to use in a controller showing each of them in use to work with the published_at date value.

The Pehapkari.cz blog has continued their series covering domain-driven design with their latest post. In this new article they focus on the implementation of the concepts they've been covering starting with the domain model.

It is great to model something and now we have reached the point where we turn the model into the code. We will implement the model, no persistence, no input, only the most important part - the domain model. The implementation will be supported by tests and we will see how easy it is to test domain objects. We will also discuss the connection to the ubiquitous language and model and practical aspect of object encapsulation.

The tutorial then starts in covering the domain model structure and includes a few things to to think about during the implementation. It talks about reading values from the object and links to the full code on GitHub (rather than fill up the post with code). The post finishes by covering testing of the model, the idea of test-driven development and how it fits in with domain-driven design.

On the Pinco.de blog there's a post that covers the use of pivot models for role management in SaaS applications. The tutorial shows how to use the Laravel Eloquent "withPivot" method and a pivot database table to create an easy to use relationship between "users" and "teams" in a PHP application.

If you have ever developed any kind of SaaS app (like Spark), you know what team level role management means. Instead of picking a bad strategy for handling roles, we can bring simple solution by using Pivot Models.

The tutorial starts by talking about "robust permission handling" and why, more often than not, a simpler role-based approach is enough. It then covers the pivot table itself, showing the code to create the table. Next comes the creation of the relationship between teams and users via the withPivot method. With the relationship in place, the article then covers attaching users to a team, generating the models and how to add permission evaluation into the model's functionality.

On the Pineco.de blog there's a new post for the Laravel users out there showing you a simple way to integrate translations handling into your models. This functionality allows you to more easily build multilingual applications without having some of the overhead of a separate translation framework.

Making you models translatable could be an issue, especially if you are running an application that is multilingual. For static texts, we can use the built-in translation engine, but for models, we need to solve a more complex issue. Let’s take a look at a simple yet flexible solution.

While the post starts with a recommendation to use a full package if you need a more robust system, it quickly moves into the simpler structure they'll be defining. The tutorial describes the "translation mechanism" from a high level and includes the code to create the database table for holding the translated content. With that in place, next up is the model to connect the application with the table and a trait to house the translation logic. This is then used directly in the template (as a translation property) to fetch the translated version of the content.

Matthias Noback has posted about CQRS (Command Query Responsibility Segregation) on his site showing how to reduce coupling and let the "model(s) evolve" that tries to break down some of the perceived complexity around the design technique.

CQRS has some reputation issues. Mainly, people will feel that it's too complicated to apply in their current projects. It will often be considered over-engineering. I think CQRS is simply misunderstood, which is the reason many people will not choose it as a design technique.

[...] CQRS alone simply means that you're making a distinction between a model that is used for changing state, and a model that is used for querying state. In fact, there's often one model that accepts "write" operations (called "write model" or "command model") and multiple models that can be used to "read" information from (called "read models", or "query models").

He goes on to talk about the more common structure in applications, a single model that handles all of the usual CRUD operations rather than having it split up. He then moves on to the topic of coupling and reducing it through the use of read-only models. He shows examples of the code for these models as well as tips for dealing with inconsistent data.

On the Laravel News site they've posted a tutorial showing you how to use the caching functionality for models based on the framework's Eloquent ORM layer. This caching makes for fewer queries to the database and can improve the overall performance of the application.

You’ve probably cached some model data in the controller before, but I am going to show you a Laravel model caching technique that’s a little more granular using Active Record models. This is a technique I originally learned about on RailsCasts.

Using a unique cache key on the model, you can cache properties and associations on your models that are automatically updated (and the cache invalidated) when the model (or associated model) is updated. A side benefit is that accessing the cached data is more portable than caching data in the controller, because it’s on the model instead of within a single controller method.

They start with an example of it in action, getting the count of comments on a news article based on a relationship. It then shows the use of the touch method to change the model's updated_at timestamp to the current time allowing you to more correctly detect when changes occur. It also includes a more automatic way of performing the same operation using the $touches class property on the model and the cacheKey method to create a unique key name for use in the caching system to reference the model contents.

On the Pehapkari.cz blog they've continued their "Domain-Driven Design" series with the latest post focusing on models.

All of us model every day. A friend tells us a joke, we imagine the situation and if we model it as is intended, we find the situation funny. A customer wants to have a new functionality and while he speaks, we try to imagine what does the customer wants - we model.

We are going to take a look at what is software modeling, how can we express the model and how can we capture key concepts.

The post starts off with an overview of what "modeling" is to get everyone on the same page. It also talks about validation of the model by domain experts and some questions to ask to ensure the model provides the right data. They include a more practical example of a shopping cart and some key concepts and constraints that might come along with it. Some illustrations are included in the post to help give a bit more visual context to the contents.

When starting out with Eloquent, it’s natural to reach for familiar operations like where and join. For more advanced users, features like scopes, accessors, and mutators offer more expressive alternatives to the query-building patterns of old.

Let’s explore another alternative that can be used as a stand-in for repetitive where statements and local scopes. This technique involves creating new Eloquent models that extend other models. By extending another model, you inherit the full functionality of the parent model, while retaining the ability to add custom methods, scopes, event listeners, etc. This is commonly referred to as “Single Table Inheritance,” but I prefer to just call it “Model Inheritance”.

He starts with an example using the User model and creating a "local scope" method to answer the "is admin?" question. He then abstracts this out even more with an Admin model that extends the User that can be used instead to refer to admin users only. He includes examples of this in use for notifications, guard classes and model factories. He ends the post with one "gotcha" to this method - the fact that relationships no longer work on the Admin model - and how to work around it.