About software design: Where I must check parameters?

Imagine I have an application that request to the user a name, a category list. When user click on save button, application will save name and category to a database.

I have a layer that get name and category from UI. This layer check if there is a name (a string with length > 0). If this is correct, it will pass name a category to another layer. Note: category is a radiobutton list where one item is always selected.

On this second layer, application will select a suitable class to save name, depending on category.

On last layer, a class will save this name on 开发者_开发问答a database. On this class I will check if name is empty or not.

My question is: where is the right place to check method's input parameters? on every layer? Maybe, I'm going to use these layers on others developments.

Is my example correct? Maybe, I can left validation on database layer and raise an exception to UI layer.

In general, in terms of the larger question about validating input that is ultimately persisted, it is best to:

• Convert the input parameters to a fully encapsulated business object as soon as possible after you receive it.

• Validate early and fail fast then to wait until you get to a lower layer -- waste of resources, waste of time, possibly more complex (more things to roll back).

• Validate the business logic once and make that part of your object instantiation process. (but note that validation of view logic and persistence logic may need to be done at the other layers and is separate from business logic)

• Model how your object is persisted using an ORM (e.g., Hibernate) so that you could work purely at the object level in memory and leave persistence as an implementation detail. Focus the business logic at the object layer.

And in terms of method validation itself, I agree with Oded -- at every layer, and it should be done immediate upon method entry. Again, this is part of the fail fast methodology. But, as I noted above, this doesn't mean you validate business logic at every method (or every layer). I'm just referring to the basic practice of validating inputs (either by assertions or explicit checks and exceptions thrown).

where is the right place to check method's input parameters? on every layer?

Yes, on every layer. This is called defense in depth.

There are different reasons to do so on each layer:

• UI/Client code: keep things responsive and avoid roundtrips when data is invalid
• Business layer: Ensure business rules are kept
• Data layer: Ensure that valid data is passed through

I disagree with the recommendation about every layer, all the time. It sounds too dogmatic to me.

All design represents a choice between functionality and cost. Your validation choices should reflect that as well.

I think your decisions should take into account the sharing and reuse of layers.

If the database is shared by more than one application, then the database cannot depend on every application validating properly. In that case, the database must validate to protect itself.

In this day and age of SQL injection attacks, I think binding and validating prior to reaching the persistence tier is a must. The schema should do what it must to ensure referential and business integrity (e.g. unique constraints on columns and required "not null"), but other validations should be done prior to hitting the database.

If the database is wholly owned by one and only one application, and there's a service that is the only gateway into the data, then validation can be done by the service. The cost of duplicating the validation on the database layer can be waived.

Likewise between the UI and the service layer.

Double validation on client and service tiers is common because the service is shared by many clients in a service oriented architecture. Today your service might be used by a browser based UI; suddenly there's a flock of mobile apps along side it that clamor for services, too. In that case the service absolutely must validate and bind each and every request.

No manufacturer polishes every surface to mirror quality. Sometimes a rough cast surface is permissible, because the benefit of grinding and polishing is negligible and the cost is too great.

Same with software.

I don't like dogmatic statements. It's better to understand the implications of your choices. Know the rules and when it's appropriate to break them.

If you're going for very loose coupling where other applications will also make use of these same layers, then I would recommend doing input checking at every step. Since each class/method should have no knowledge of expectation of the other classes/methods which ran before them in the stack, each one should enforce its requirements individually.

• If the UI requires that a value be in the text box when the button is clicked, it should validate accordingly.
• If the business logic requires that a name never be null/empty, it shouldn't allow a null/empty value to be placed in that property.
• If the data layer has a constraint on that field requiring that a value be present, it should check that a value is present before trying to persist the data.