The Toptal.com blog has a tutorial posted by Elvira Sheina showing you how to keep a framework project "slim" and manageable in a MVC pattern using a "layered" structure. This structure adds a few extra components to the traditional MVC design to keep functionality cleaner and easier to maintain.

Fat controllers and models: an inevitable problem for most large-scale projects based on MVC frameworks such as Yii and Laravel. The primary thing that fattens controllers and models is the Active Record, a powerful and essential component of such frameworks.

She starts by talking about one of the main issues in MVC applications - "fat" controllers. In this example the controllers contain the bulk of the logic for the application making it difficult to modify and potentially reuse in other places. This is particularly bad when the Active Record pattern is used and the problem of it violating the SRP (Single Responsibility Principle of SOLID development). Instead she promotes the idea of the "layered" design using controllers, a service layer, DTOs, view decorators and a repository layer. She then shows how to implement this kind of structure and tie each of the pieces together with code examples for each piece.

In a new post from the Dotdev.co site there's a tutorial from Amo Chohan helping you write advanced search query filters for Eloquent in your Laravel application.

I recently needed to implement a search feature in an events management project I was building. What begun as a few simple options (searching by name, e-mail etc), turned into a pretty large set of parameters.

Today, I’ll go over the process I went through and how I built a flexible and scalable search system. For those of you who are eager to see the final code, head over to the Git repository to see the code.

He starts off by outlining what he'll be creating and where the need comes from for this more advanced filtering. He uses a company-wide calendar example with events and meetings/clients shown for all users. He defines the filters he knows he'll want to search by and the models relating to the data needed for those queries. He then spends the rest of the post going through the code needed to implement the filtering, starting with a rough (but working) version and refactoring from there. He moves away from the procedural method of applying filters to a query object directly and over to "applying" them more dynamically using a set of filter instances via a Decorator design pattern approach.

The NetTuts.com site has continued their series looking at design patterns and how they can be used in PHP. In this new post they focus in on the Decorator pattern, most commonly used to add functionality to a existing class (to "decorate" it).

Earlier in this series we explored both the facade and adapter design patterns in this series. Using facade, we can simplify large systems, and by implementing adapter we can stay safe while working with external API and classes. Now we are going to cover the decorator design pattern, which also falls under the category of structural patterns. We can use the decorator pattern when we just want to give some added responsibility to our base class. This design pattern is a great alternative to a sub‑classing feature for extending functionality with some added advantages.

They start with a problem that needs solving - sending an email with additional content not defined in the parent class. They show how to do something similar with child classes, but quickly find a limitation. Instead, they show how to use decorator classes and a simple interface to provide interchangeable classes that augment the contents of the email body as passed in via constructor injection.

PHPMaster.com has posted the second part in their series looking at design patterns in handling views in your framework of choice. In this new article they focus on the decorator pattern, using additional functionality to augment the results from the view being rendered.

It's also feasible to manipulate views in fairly flexible fashion by appealing to the niceties of a few other patterns as well, including the rather underrated Decorators. If you're wondering in what parallel universe Decorators get along with views, in this part I'll be showing how to put them to work side by side in nice orchestration to bring to life yet another view module.

They create a simple example where an HTML element (based on an interface) is rendered - a span tag - with content passed in on creation. They take this same logic and transfer it over to the View handler, making handlers for difference pieces of the content (outer and inner). These decorators are then passed in the data from the view and rendered in order.

On his MaltBlue.com site today, Matt Setter has a new post showing you how to use the Zend_Form ViewScript decorator in your Zend Framework-based application's forms.

If you've been using Zend Forms for any length of time, you'll know just how flexible and configurable they are. [...] We can, as I'm quite fond of, use the ViewScript decorator. This allows us to have nearly 100% control of the configuration of the look and feel of our rendered forms.

The ViewScript decorator lets you have full control over the layout of your form, letting you use a view (file) to define the markup for the form and injecting your elements into it. There is an issue with using the form in other modules though - it can't find the view file by default. The solution is to pass in a viewModule when using the form, showing it where it can find the view.

Anthony Ferrara has a new post today looking at plugin handling and a few of the more common design patterns that can be used to implement them in your applications.

A common problem that developers face when building applications is how to allow the application to be "plug-able" at runtime. Meaning, to allow non-core code to modify the way an application is processed at runtime. There are a lot of different ways that this can be done, and lots of examples of it in real life. Over a year ago, I wrote a StackOverflow Answer on this topic. However, I think it deserves another look. So let's look at some patterns and common implementations.

The patterns he covers are:

• Observer
• Mediator
• Strategy
• Decorator
• Chain of Responsibility

For each there's both a bit of sample code showing it in use and links to some examples from various frameworks and other projects.

On his blog today Jason Gilmore has a quick post about solving one of his frustrations with Zend_Form (a part of the Zend Framework) - the default form decorators.

It is a fantastically productive framework, one which I happen to use almost every single day. There was however one feature which absolutely drove me crazy. The Zend_Form component's uses the dd, dl, and dt elements as the default form markup decorators, meaning that even a simple contact form consisting of name, email, and message fields and a submit button [is marked up with dl, dt and dds]. [...] It goes without saying that the overwhelming majority of developers do not use these elements to mark up their forms, with the sheer number of questions posted to StackOverflow and elsewhere about getting rid of these decorators backing this assertion.

He gives his simple solution to the issue, something better than removing all of the decorators and using setDecorator to replace them - a simple partial view that echos out the fields directly. The trick is to use the setDecorators call with a "ViewScript" option pointing to your partial and setElementDecorators() call to use a "ViewHelper".

On the Zend Developer Zone there's a new article from Keith Casey where he talks about some of his favorite design patterns he's come across in his time as a developer - adapter, facade and decorator.

Within the Design Patterns world, there are four main categories: Architectural, Structural, Creational, and Behavioral. Architectural patterns describe the system as a whole, Structural patterns describe the relationships between objects, Creational handle creating objects, and finally Behavioral describe the communication patterns between objects. Each of the categories is worth discussion on its own, but in this case we'll stick to the Structural patterns of Adapter, Facade, and Decorator.

He describes each of the patterns (no code in this one, just descriptions) and for each mentions some of the tools that the Zend Framework has to offer that match up. For example, the Adapter pattern is used in quite a few places in the framework including in the Zend_Db component for the connection types to different databases.

Gonzalo Ayuso has a new post to his blog looking at some of the recent work he's done with PHPDoc and annotations to create "function decorators" in his code.

The idea is to solve the same problem I had when I wrote the previous article. I want to protect the execution of certain functions in a class to only being executed if the user is logged on. [...] The solution with interfaces is clean and simple (no extra libraries need and no reflection need too). The problem is that I can use it only for all the functions of the class.

He gives an example class with four different methods (one with annotations) and his annotation parsing class that runs the predispatch and postdispatch methods based on those annotations. He also shows another examples using an abstract class.

Tom Rawcliffe has posted the latest installment of his look at design patterns in PHP. This time his focus is on the Decorator pattern.

Continuing my series on PHP design patterns, today it’s the turn of the Decorator. In contrast to last week’s Strategy Pattern which is used to change the “guts” of a class, the Decorator Pattern is used to extend the behavior of a class with different functionality at run time. This is achieved by implementing a “decorator” class that implements the same interface as the object that you wish to “decorate” and wraps it’s content.

The Decorator pattern lets you "decorate" your objects with additional features. He illustrates with a sample "Property" class (that implements an interface) that he wants to extend past the normal property handling. He add a "PropertyDecorator" to the mix that lets it use deocrators for uppercasing and padding the string. There's an example script included at the end that shows how to put it all to use.