是否将其视为验证逻辑的重复？

Question

I have sample class like this

public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int ContactNumber { get; set; }
    public System.DateTime DateOfBirth { get; set; }
}

All of these fields are required before adding a customer to the database. So in the service/business logic layer I do validation for these 4 properties. I validate that FirstName and LastName are not empty and ContactNumber is greater than 0 and DateOfBirth is greater than 1930(just as an example). In the aspx page before I can pass the customer object to the service/business logic layer to validate and add to database, I do type checking for ContactNumber and DateOfBirth. I use simple functions like IsNumeric and IsDate.

I know the validation is supposed to be done in the service layer so that if another app needs to use this logic in the future duplication can be avoided.

Is it common to do type checking in the aspx page and then pass the object to the service layer which does all the other validation? I know one way to avoid this is to use javascript. For the sake of argument(never really happens) client turns off his javascript. Another option I was thinking about is the function that adds customer to the database accepts all its parameters as objects. This way type checking can be avoided in aspx page and just be done in service layer. But what if there are like 20 properties that I have send as method parameters?

Answer 1

You should be validating at both the client and the server.

The JavaScript validation would be performed on the client side and would reduce the number of round trips to the server if the user has simply made a mistake and forgotten to enter their details. This would also provide a better user experience.

The server side validation is crucial and should also be performed. If the user ever disables JavaScript or an attacker sends malicious form values to your server then this validation would kick in. Since you are using WebForms you can use the Validation Controls within the framework, for example: RegularExpressionValidator and have a Validation Summary.

If you wanted to do the validation yourself then this logic would best sit in a ValidationService as you describe which could accept the Customer class as an argument rather than the 20 properties you stated in your question.

You may also want to consider using other libraries to prevent attacks such as XSS.

Answer 2

It really all depends on your design and needs. The points you mentioned are all valid points. Yes, ideally you need to do the validation in the service/business layer in case more than one presentation layer is calling it, but also because the service/business layer is the one that is responsible for the business logic.

However, you are also right that often some validation is done in the presentation layer for several reasons: It is the one interacting with the user and displaying the validation errors. Also some validation techniques can only be done in the presentation layer, example JavaScript which is used to make the validation much more responsive without a need for trips to the server every time. However, JavaScript validation is only used to enhanced the user experience, but never depend on it as a real validation because it is easy to bypass it.

So from the design perspective, your validation in the service/business layer and presentation layer is considered to be a good design and not bad duplication of efforts.

However, practice sometimes does not follow the theory exactly. For example, some validation could be very long and expensive to perform twice. In such a case, perhaps the only place you want to put such a validation is the service/business layer.