constraint-annotationd-definition.php

Solution 1:

Constraints can be defined on the top level.

Advantages:
Little code

Disadvantage:
Min does not have a context. If multiple constraints of the same type exist,
they need to be wrapped in another annotation.

<?php

/**
 * @Min(5)
 * @Email
 * @ConstraintList({@Max(limit=10, groups=Admin), @Max(limit=7, groups=User)})
 */
protected $myProperty;

?>

Solution 2:

Constraints are always defined in an outer annotation.

Advantage:
Constraints have a context, no extra treatment of duplicate constraints necessary

Disadvantage:
More code, especially if you only define a single constraint

<?php

/**
 * @Validation({
 *   @Min(5),
 *   @Email,
 *   @Max(limit=10, groups=Admin),
 *   @Max(limit=15, groups=User)
 * })
 */
protected $myProperty;

?>

Whats the difference of the @Validation and @ContstraintList ?

Not much. The difference lies in the concept, which is described in the text above.

I like the second solution better, because it provides context to MIN, MAX and etc. annotations, and lets me know that those are Validation related.

The second solution is the way it is implemented for now.

I prefer the second solution, even if it's a little more verbose.

The first solution does not seem right when you add other annotations (like Doctrine 2.0) :

/**
 * @Column(name="username", type="string", length=255, unique=true)
 * @Min(5)
 * @Email
 * @ConstraintList({@Max(limit=10, groups=Admin), @Max(limit=7, groups=User)})
 */

+1 for solution number 2