1

I believe that DTO should be as dummy and easy as possible. However, after hint made by my friend, opportunity to validate data that is set in DTO sounds tempting.

Let's have following example:

//this class only holds bunch of objects from the future

class FooFuture{

    /** @var ArrayObject */
    $collection;

    (other fields ommited for readability)

    /**
     * @param ArrayObject $collection
     */
    public function __construct(ArrayObject $collection = null){

         if(null === $collection){
             $this->collection = new ArrayObject();
         } else {
             $this->collection = $collection;
         } 
    }

    /**
     * @param ArrayObject $col
     */
    public function setCollection(ArrayObject $col){

        $now = new DateTime();        

        foreach($col as $element){
            if($element->getDateTime() < $now){
                throw new InvalidArgumentException('Collection should only contain objects from the future');
            }
        }
    }

    /** 
     * @return ArrayObject
     */
    public function getCollection(){
         return $this->collection;
    }

}

What do you think?

  • 1
    The short answer is "as long as you won't regret (having put the validation into DTO but then had to take it out)". The circumstances that will cause you to regret are somewhat specific to your projects. Can you describe how far ahead in time $element->getDateTime() will be? – rwong Sep 9 '15 at 9:15
  • It's between today and next 8 weeks. – ex3v Sep 9 '15 at 9:21
  • Is there any chance that the DTO will be set to a time that is very close to now, e.g. a few seconds or minutes later? If so, it might pass validation at this very second, and then fail validation after maybe a little bit of computation or user interaction. This is my main reservation about the idea - not against validation, but worried about the use of $now. – rwong Sep 9 '15 at 9:35
  • 1
    Maybe I simplified this too much. Let's take appointments list for example - I want to have all of today's and future's appointments in this DTO, even if there's one that's set on 9 am, and it's already 5 pm. So, in other words, it's more about dates than hours. DTO will live just for few miliseconds, so this is an edge case. – ex3v Sep 9 '15 at 9:39
2

While i agree that it can be usefull to have validation for dto-s i think that dto-s should be as simple as possible.

You can achive boths if you are using a programming language that supports Interfaces like java or c# and put the validation logic into a seperate class that consumes interfaces.

Example

public interface IOrder { ... }

public class OrderDTO implements IOrder { ... }

public class OrderBuisinessObject implements IOrder { ... }

public class OrderValidator {
   void validate(IOrder anOrder) { ... }
}

To answer your question: yes to have validation but not in dto

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.