Defensive programming

🕑 Estimated reading time: 4mn

Table of Contents

Good or Bad repository?

By Arnaud Langlade, Developer @ Akeneo / Sylios
AFUP page - Slides

A repository must represent a collection of objects and not an entire project. The base contract of a repository should only contain an “add”, a “get”, a “remove” and a “nextID” function. These functions may throw a \LogicException whenever they reach an undesired situation such as when “get” returns nothing. Finally, always use UUIDs as identifiers to hide the sequences of stored entities.

A proposed practice is to extract the reading capabilities of the repositories in a separate pattern: query functions. This way, Repositories will only be used for writing purposes and Query functions will read data and hydrate custom entities. Even though this does not suit the pure Repository pattern, it allows developers to create immutable data structures.

Query functions allow developers to spend less time on ORMs and get more performance by directly querying the database with SQL. This practice might introduce vulnerabilities under the form of SQL injections so it is necessary to be very careful! Finally, whenever a query function becomes unmantainable, it is recommended to divide it in subfunctions and helpers.

Tips and tricks:

Defensive programming

By Nicolas Perussel, PHP Architect @ ekino

Defensive programming can be seen as a collection of practices that will solidify your code in order to prevent future breakage by other developers. It is mostly used when High Availability or security are top priorities but can be applied any time and for any language.