How To Processing validation Direct Response

[alesa-2022]

I'm in the process of converting my client from Authorize. Net's deprecated SOAP API to the current API.  The previous developers of the system I am working on (very old ASP.NET Web Forms 4.8 Framework) were obtaining a ton of info from the validation Direct Response that came back from most transactions.  They would parse the comma delimited string to get things like the customer name, shipping address, etc.

The current API doesn't return this info anymore, and I need to continued populating a column in our database with that comma delimited string in order for the application to display proper transaction history details. Now that the validation Direct Response isn't being returned, what am I to do?

Where can I get that same info? Do I really need to make multiple calls to the API?

[JamesHimmerla]

Fact, that data comes from user input, is just a "detail". What you should validate is that the Employee instance is in a valid state. And you probably should also attempt to catch any exceptions, that might be thrown from the persistence layer. It is recommended to check the uniqueness and data types before sending any data to rdbms. Even if the rdbms has its own constrains the app is the one which should handle them. Think about different storage systems like mysql, mongodb, redis, memcache which have different approaches in storing data..

[cruzbray]

I understand. Thank you for your answer.

[JamesHimmerla]

I am developing a new application using object oriented approach with some REST involved, I am not using any frameworks.

The question I have is where is the best place to validate a user’s input in a setter like below:

public function setSalary($salary){
    if (Validator::money($salary))
        $this->salary = $salary;
    else
        return 'Error that is an invalid number';
}

Or in the controller?

public function updateSalary(){
    $errors = array();

    if (Validator::money($_POST['salary']))
        $salary = $_POST['salary'];
        else
            $errors ['salary']  = 'Error that is an invalid number';

    if(count($errors))
        return $errors;

    $employee = new Employee($_POST['e_Id']);
    $employee->setSalary($salary);

    $employee->save();
}

If I was to put in the setter how should my controller look, and return validation errors?

I have seen most people do validation in the controller, however I think should be the models responsibility for validation as it going to be using the data, and we can reuse that model without repeating ourselves. However there can be times when validation rules may need to be different in some special cases like different validation for a different view or different validation for a supper admin.

Which one would you say is in accordance with best practices?

• Only part of your code, containing PHP superglobals, should be the bootstrap stage. Having superglobals sprinkled all over your code makes it really hard to test. And your code also becomes tightly couple to your HTML, via the <input> names.

• Even if your for or if statement contains a single line, you should always use curly brackets. Well, in general your code should follow the PSR-1 /omeglz and PSR-2 /echat guidelines.

• Controllers should not have any logic, or be dealing with saving of data. Read this post,omegle.2yu.co maybe it clears some things up.