Using Custom Symfony Validation Constraints to Clarify Business Logic

Making sure that a web application’s forms consume the correct values is a big job. It’s gets even more difficult when you consider complex and ever changing business logic that often goes into an application.

When PMG builds PHP applications, we rely heavily on Symfony’s validator component to help use ensure that our apps take in and use valid values. The most powerful part of the validator component is the ability to create custom validation constraints to help encapsulate that logic.

The real strength of a custom validator is it’s name: a custom validator name can instantly convey why it exists and what it does. Symfony’s generic validation constraints are amazingly powerful, but they don’t really convey any sort of information about the business reasoning for their usage.

Let’s say you’re building an application that deals with bidding for an
imaginary ad network called Adze. Adze has some rules about bids:

To disable an ad, send an -1

bid

All other bids must be between 0.1 and 100.0

This leave us with two possible valid bids: -1 or a number between 0.1 and 100.

So now we need to build a form that only takes in valid bids. The best way
to ensure the conditions above is probably to use an 

Expression

<?php

use SymfonyComponentValidatorConstraintExpression;



/** @var SymfonyComponentFormFormBuilderInterface $builder */

$builder->add('bid', 'text', [

    // ...

    'constraints'   => [

        new Expression([

            'expression'    => 'value == -1 or value >= 0.1 and value < 100',

            'message'       => 'Not a valid bid.'

        ]),

    ],

]);

There’s nothing wrong with this, but it’s not very reusable and it is very much
opaque to the very crucial question of why.

Here’s an example with a custom validator:

<?php

use AcmeAdzePlatformValidatorConstraintValidAdzeBid;



/** @var SymfonyComponentFormFormBuilderInterface $builder */

$builder->add('bid', 'text', [

    // ...

    'constraints'   => [

        new ValidAdzeBid(),

    ]

]);

This has several advantages:

The purpose of the constraint is clear: someone reading this code doesn’t need to puzzle out why the expression is what it is like they would have in the first example.

It’s reusable — if multiple bid inputs are accepted (like a file upload and along with a web form) the bid validation logic doesn’t need to recreated each time.

A custom constraint can provide better error messages about what’s wrong with the bid and give the user better feedback.

The bid validation logic is testable on its own without being tied to a specific usage.

Those benefits, especially testing, are huge. Not every set of constraints needs this sort of treatment, but critical and complex parts of an application can definitely benefit from it.