You think handling forms it’s the only way? But, is there any options? Practical benefits of using Value Object instead of Form Let’s consider how Value Object (VO) “ may help you in handling web forms and simplify your life. design pattern” Form Suppose we need handle HTTP request in PHP (both cases: “application/x-www-form-urlencoded” or “application/json” it’s super simple to convert parameters from both requests and use them to fill form in PHP).Usually we do something like this (here I’m going to use because it’s pretty straightforward, simple enough, popular and you can find it on github): symfony/form create class: form Create form instance: $task = new Form(); Fill form with parameters from HTTP request: $form->handleRequest($request); And now we can deal with this form. Nothing difficult so far…But hold on… let’s answer next questions: Is this form valid? Was all parameters populated with values from request? Can I modify any parameter value? Can I loosely re-use this form in downstream services, layers, etc? Answers: Have no idea, have to run: $form->isValid() Not sure. If someone missed (which is rare but technically possible): it means form contains blank initialized values, in our case will return . $form->handleRequest($request); $form->getName() null Yes. Just call public setter. Definitely no. Because form can contain not only valid values but also invalid values and it means that we have to flood services with code like: if ($form->isSubmitted() && $form->isValid()) {// ...} Value Object Let’s handle same HTTP request: create VO class: Create VO instance: $vo = new ValueObject($request); And that’s it, no additional steps required. Let’s answer previous questions: Is this VO valid? Was all parameters populated with values from request? Can I modify any parameter value? Can I loosely re-use this VO in downstream services, layers, etc? Answers: Yes! Since VO created — it is valid, because VO contains self validation in method. VO won’t be created if provided invalid parameters, exception will be thrown. __costruct Yes! Otherwise exception will be thrown and VO won’t be created. No! VO is immutable, you can’t change anything. Yes! VO always valid and you can rely on it on any application layer, you can use it as type hint in methods, like: and you don’t have to flood your code with redundant blocks (more declarative style). public function doSomething(ValueObject $vo) if Criticism You may consider that write all validation stuff in constructor might be overwhelming — I’ve used here just small simple example, with purpose to provide the main idea in a simplest way. But you may consider option to use something like more information you can find . kint/vo here Also you may consider exception during as flood your code with blocks, but in real life you have to have only 1 such block for whole application (no matter how it’s big) which will catch your custom exceptions and will provide all errors into response, like in case with you have just catch in 1 place. __construct try-catch kint/vo ValueObject\Exception\ValidationException In case you don’t like to have all this stuff in Value Object’s constructor and don’t want to use keyword, you may consider next example: new the main idea stay the same, the only difference — is the way how you create ( ) and use your Value Object. $vo = ValueObject::fromArray([‘namex’ => ‘bond’]); Conclusion Now you know how Value Object can help you to write more strict, robust, immutable code in declarative style. Hope this article was helpful and you will use VO not only to handle HTTP requests but also to build whole interaction between your components, services, etc. in your application.
