Geek Answers Handbook

Confirm form input in installers of domain objects?

Since I learned about MVC, I always checked my form data in my controllers, which I used to when I looked at CodeIgniters code, but I found out that its way of doing certain operations is not the best, it just does its job.

Should all data be validated by domain objects? And if so it should be done in setters like this:

public function setFirstName($firstName) { // Check if the field was required if(!$firstName) { throw new InvalidArgumentException('The "First name" field is required'); } // Check the length of the data // Check the format // Etc etc }

Also, for example, if I handle basic user registration, my User class does not have the $confirmPassword , so I won’t do

$user->setConfirmPassword($confirmPassword); .

One way to check if the two entered passwords match is to set $password and do something like

 $user->setPassword($password); if(!$user->matchPassword($confirmPassword)) { throw new PasswordsNotEqualException('Some message'); }

and it will be done at the service level, which I would have thought?

Any advice that would help me in the right direction would be great. Thanks.

+4
source share
2 answers

Should all data be validated by domain objects? And if so, should this be done in setters this way

IMO, you must allow the creation of valid objects, and the best way to archive this is to do these checks in the method that creates the object.

Assuming that the username cannot be changed, you must confirm this when creating the user. Thus, you forget about the installer because you no longer need it.

There may be times when you want to change a property and you also need to check them (because this change can lead to a valid object for an invalid object if that happens).

One way to check if the two entered passwords are the same is to set the password $ and do something like ...

You can deal with this in the same way: have a Password object that verifies the password and confirmation when it is created. You have a valid copy of the password, you can use it, knowing that it passed all the checks that you specified.

References

These design principles (complete and valid objects from the very beginning, etc.) refer to Hernan Wilkinson's "Design Principles for Patagonia." Be sure to check out ESUG 2010 and presentation slides .

I recently answered another question about property validation. I think you might find it useful: fooobar.com/questions/339277 / ...

Hooray!

+3
source

TL DR

No, setters should not check data. And nick2083 is completely wrong.

Longer version ...

According to Tim Howard, a definition was given [source] domain objects can check the status of the domain information that they contain. Basically, this means that for the actual existence of a domain object, the specified object must be able to verify itself.

When to confirm

Basically you have options:

  • check in every network device
  • has one method for checking the integrity of an object

If validation is part of the setter, there is one major flaw: the order of settings.

Example: allows you to claim that you are making an application that deals with life insurance. It is likely that you will have a domain object that contains the insured person, and the person who received the premium when the policy is initiated (the insured does not die). You must make sure that the beneficiary and the insured are not the same person. But there is no rule to control the order in which you execute setters.

When you have two or more parameters in a domain object that need to be checked against each other, the implementation becomes a little fuzzy. The most acceptable solution is to check when all the parameters are assigned, but at this point you have already lost the advantage of checking in setters: code execution passed the source of invalid data.

And how would you handle situations where the actual state of a domain object does not have parameter A, if parameter B is large, then 21 and C are already set?

Conclusion: validation in setters is only a viable solution when you have very simple domain objects, without any confusing validation rules.

+3
source

More articles:


All Articles