2

Sorry in advance if this question is so trivial.

The situation

There is a Customer entity whose ID is limited to two letters (A to Z) in the database.

Also, a user can enter the ID value from a Windows form. I think that the best option is that this form will validate (using the controller) with a regular expression like this ^[a-zA-Z0-9]{2}$ whether the value is valid.

The question(s)

  • Does the Customer entity should also do the validation when I set the value of the ID property?
  • Should this validation be outsourced if, for example, there is also similar validation in other properties of the entity?

I think that the answer is that it depends if the property value is a requirement of the user or it is a design decision on the database, but I appreciate your knowledge and experience to guide me on the correct way.

Thanks in advance.

HuorSwords
  • 155
  • 5

3 Answers3

2

If there is a client application, you don't normally do any data validation in the database unless it would cause the database to throw an error e.g. NULL when a value was expected.

If there are a range of valid values however, it isn't uncommon to store these in the database and then make them available to the client application. This is sometimes known as metadata.

For belt and braces defensive coding, it sounds like having data validation in multiple places is a good idea but should you wish to change this, you'd have to update the logic in both places. Validation is best placed in a single layer (i.e. single source of truth) rather than sprinkled throughout the solution.

Robbie Dee
  • 9,815
  • 2
  • 24
  • 53
  • Thank you for your answer. In this case, the ID column on the database is defined as CHAR(2), so a database error will be thrown when the ID value exceeds the maximum length. This and the "only-letter" restriction is set also by the final user on his specs. Then, if I don't validate value length before introducing it into the database, there is a problem. – HuorSwords Jun 17 '14 at 14:21
  • There are various ways to handle this client side. E.g. if you're using a textbox to enter the ID, you can set the MaxLength property to 2. – Robbie Dee Jun 17 '14 at 14:27
  • You are right. I think my question is not clear. Supose that: You can serialize a Customer object from XML file. The validation of the serialization will remain on Customer object itself or outside of the object (assumming SRP)? – HuorSwords Jun 17 '14 at 14:31
  • Yes, it would make sense to do the validation in the object itself in that case. ID length would be a static property or similar which could be pushed through to the form at runtime. – Robbie Dee Jun 17 '14 at 14:49
  • Why not allow each layer handle its won set of validations? Database will handle validations based on constraints. DAL will handle what is critical to it. Application will handle what is related to it. I agree this spreads the validations through all layers but the scope is well defined for each layer. – Amit Joshi Jun 10 '17 at 08:12
0

If your validation is done at a database level you're working through layers of code to get there. That's expensive, why pass down data only to find out it's wrong? You may be opening long running pointless transactions impacting every user of the application. Not only that but SQL validation is far less flexible than what you can do in JS/C# or any of the other languages available to you.

I would recommend validating as high up the stack as is possible/sensible (obviously if you have multiple UIs don't write it out several times). UI is good, domain objects is good (although I like to keep these as pocos), BLL is common.

Wherever you put it make sure you're consistent so you can find it later!

Liath
  • 3,426
  • 1
  • 21
  • 33
0

I personally prefer to spread validations across layers based on well defined scope.

  1. Database
    These set of validations could be imposed based on constraints. These should NOT be validated again in any layer with some exceptions. Example UNIQUE, NOT NULL, Max Length, Data Type etc. Database will not accept the data that does not satisfy the constraint. Validating this again in some layer is useless in most cases.
    UI can repeat some of these validations based on need like null check, uniqueness if all data already available in UI. To check uniqueness in case all data is not available at UI, only way is to do database call. Instead, let the database throw exception. Each way costs the same. Instead of writing code, length validation could be imposed by setting maximum length property of control.

  2. Service (BLL)
    We may have some business rules those should be followed by entity. Example, my application expects the weight of person in digit only in kilogram unit. So the valid values are in format "000.000" only. I do not prefer to enforce this on database side. I prefer to do this in service. Other example is the person gender should be either M or F for my application. In database, this is CHAR (1). Again, I prefer to handle this in service layer instead of database. UI generally do not handle this at all. It simply chooses controls to get inputs properly. Combo box or option buttons for Gender is good; no need to write additional code.

  3. UI (Application)
    Anything that does not fall in above two could fit here. Good part of these validations should be handled through correct choice of controls.
Amit Joshi
  • 111