The Pineco.de site has a new tutorial posted showing you how to implement custom logic with raw SQL in the Eloquent query builder in the Laravel framework.

Laravel’s query builder offers a nice way to work with raw SQL. We can use them in our where conditions and also in our orderings as well. Let’s see some examples where we can use raw SQL to implement custom logic for ordering the results.

The post starts with a brief mention of the difference between sorting and ordering results, noting that one happens on the SQL server and the other on the results collection. Next they show examples using raw SQL to order a query using both a simple and more complex condition. There's also a link to the official documentation for the raw methods for more information and examples.

In a post on his Medium site Joey Masip Romeu shares some suggestions about how you can organize your business logic in a Symfony application with some simple namespacing and service definitions.

I want to talk about namespacing services in Symfony, specifically Symfony3.

These are exciting times, Symfony 4 is just round the corner?— -coming out on November 30th? - ?so this blog post might be irrelevant soon! Nevertheless, concepts are still the same so let´s get into it!

He offers three "rules" that he and his team at SlowCode have defined to help with their own organization:

• using a folder for logic services
• using a folder for the domain name
• using . for folder separation and _ for word separation

Code and configuration examples are provided for each suggestion helping to illustrate the point. He ends the post mentioning public and private services and how they're changing in upcoming Symfony releases.

On the Pineco.de site there's a tutorial posted showing you how to implement the Laravel auth system on the frontend re-using the same logic in a single-page Vue.js application as you would on the backend.

If you are using Laravel, probably you are familiar with its ACL. You can easily restrict user’s access by creating policies and binding them to the specific models. It works perfectly on the back-end, but what can we do if our app is something like an SPA?

The post starts with a brief overview of the Laravel ACL handling as it relates to users and policies about what they can do or access. The frontend setup then makes use of a "cheap copy" of the Laravel "gate" handling via a Javascript-based request. They walk you through the preparation work you'll need and the creation of a gate class to define the current policies for CRUD methods. The main "Gate" class is then defined, setting up the before, allow and deny action methods. Finally these pieces are integrated into the Vue.js application with an example of either showing or hiding the "Edit" link based on the user permissions.

In a new post to his site Paul Jones shares some of his thoughts about microframeworks, suggesting they're more "user interface" frameworks. Basically he suggests that microframeworks work best for the UI level handling and that possibly a second, more robust framework should be used for the application backend.

When we talk about “full stack” frameworks, we mean something that incorporates tools for every part of a server-side application. [...] Examples in PHP include Cake, CodeIgniter, Fuel, Kohana, Laravel, Opulence, Symfony, Yii, Zend Framework, and too many others to count.

When we talk about “micro” frameworks, we mean something that concentrates primarily on the request-handling and response-building parts of a server-side application, and leaves everything else out. [...] If the user interface is the request (as input), and the response (as output), that means micro-frameworks are not so much “micro” frameworks, as they are “user interface” frameworks.

He suggests that, if these statements are true, then microframeworks should be considered "user interface" frameworks. He makes suggestions of splitting things out into "containers" of functionality with the microframework taking care of user interactions while a second handles domain and infrastructure concerns.

In a recent post to his site Marco Bunge offers some suggestions on how to write good application logic in a "clean, testable and reusable" way.

Web based enterprise applications are often accessible via different user interfaces through protocols like HTTP, Sockets, RPC, CLI. The Model-View-Controller is still present as a user-interface pattern. But requests and responses needs to be handled in the way of their interface requirements.

We don’t want to write the same logic for each required interfaces. Furthermore we don’t want to test and maintain code for each required interfaces. We want to write, test and maintain reusable source code at a central point of the application eco-system.

He then talks about the ideas behind the "three-teir architecture" and how this structure can be used to split logic into layers: presentation, logic and data. He mentions domain driven design as a development method to help achieve this structure and his meaning of the word "clean". He then gets into the implementation of this structure, defining the major pieces of functionality for each tier (with code for each included). He ends the post with some suggestions of points for additional reading about things like presenters, the ADR pattern and the "Inversion of Control" principle.

Paul Jones has a new post on his site sharing some of his thoughts about the placement of domain logic and email templates in an ADR (Action/Domain/Responder) structure. The post is an answer to a recent question he received asking how to organize emails being sent by service classes.

In a way, sending an email as part of a web request/response cycle is like sending two responses: the normal HTTP response, and the email response. With that in mind, it might make sense to think of the HTML + Text email templates as part of a presentation layer. Or, as a combination of infrastructure (the email-sending client) plus presentation (the templates). That would be how to think about the separation of concerns there.

He then provides what he sees as a good directory structure to help keep it all separated out. He also talks about the load sending emails can put on a system, when to move it to workers and how that impacts where the templating of the emails should be done.

The QaFoo blog has posted a new article sharing five tips to improve your unit testing of your PHP applications. Even if you're a testing veteran, there's some helpful hints in here for you.

After you got the hang of unit testing there is still so much space for improvement. In this post I want to share five tips with advanced testers I have seen to influence testing in the right direction.

Their list of five tips includes advice about what you should consider as a "unit", refactoring test code and writing tests for bugs. Each topic includes a brief description of the suggestion and clear steps to follow when integrating it into your testing workflow.

Freek Van der Herten has a quick post to his site with a tip about simplifying presenters in your Laravel based application. The "presenters" here are in relation to this package and how it helps with the output of the application.

In the Laravel template that we use to kickstart all our client projects at Spatie, I recently changed the way we handle presenters. Instead of using Jeffrey Way’s popular presenter package we now use simple traits. In this post I want to give some background on that change.

He gives a quick "crash course" on presenters for those not familiar with the concept and how it helps to keep view logic out of places like models and controllers. He briefly describes a presenter class that would return the "first name + last name" combination and what the code could look like. Then it's just a matter of using that trait (the class mentioned just before this) and a new magic property is defined to use in the view.

On the Graze.com Tech blog there's a recent post about sharing logic between controllers with the help of traits. He makes use of the traits functionality in PHP to abstract out functionality common to multiple controllers (in his case, common user functionality).

There have been a few times I have come across a situation where I need to share some logic between controllers but it hasn't been as clear cut as abstracting that logic out into a library. I've been pondering the best way to tackle this problem and would like to share my thoughts.

In his example he shows how two different controllers, the Account and Signup controllers, both need to be able to look up an address and perform some simple checks on the results. The logic is duplicated so he first tries to move it out to an abstract controller but notes that it's not the most ideal solution. Next he tries moving the code out into a library but finds issues with separating out the necessary concerns. Finally he moves the logic into a trait (AddAddressTrait) that contains it and allows the direct integration of his "lookupPostalCode" method into the controller without inheritance or other design issues.

In this new post to his site Stephan Hochdörfer covers some of his own thoughts about the recently proposed application structure from Paul Jones, the "Action-Domain-Response" pattern. In this post Stephan compares the typical controller classes with an action class.

First of all I do have the feeling that controller classes make it harder to structure your logic. I have seen a lot of "God Controllers" that do a shitload of stuff. Stuff that is not really related to each other. [...] action classes tend to be rather small, typically less than 100 loc for us. That also helps a lot when trying to understand what`s going on. I am aware that there are developers out there who are afraid when it comes to dealing with a lot of classes. [...] That`s another bonus point for action classes: It is easier to search for a class name than a method name in most IDEs.

He goes on to talk more about "God controller" classes, their dependencies and how that compares to action classes only taking in what they need. He touches on the reusability of action classes as opposed to controllers and how they come in handy for storing common logic.