BL vs DAL when validation requires the DB

Question

I am planning to put validation logic in business logic layer which could include things like:

[Required], [Length > 0], etc. Using data annotations. However, I also need a validation rule that checks that the object is not a duplicate before having the DAL insert into the database, e.g. [IsDuplicate]. So, question is, where to put [IsDuplicate] validation rule? If I put it in my BL, then this will violate my current 3-tier setup where the BL has no knowledge of the DAL. I guess the question really becomes, is checking for duplicates considered a validation rule or something else?

Answer 1

Your question is ambiguous. It depends on what kind of record and what kind of operation do you refer.

If you refer to one to many record, like:

header --> many details

BL

Then the duplication check is being done in BL. That is, example, validate if the detail of a header must not contain two or more same item code, etc. And if the process is accepting array of headers, the duplicated header validation is also done in BL.

Other validation rules like minimum length, string format, null values, etc also done in BL. It can be automatically re-validated in DB though if you using some constraints and data length / isnull data type.

DAL

However, when you want to validate if the header id already exists in DB, do it in DAL. That is because BL don't know what it is in repository. It is DAL's responsibility.

There is some cases where you don't need to do validation first though, example if the header table already has unique index, it will throw exception and you just need to catch it. However for specific DB validation check like: item does not exists, item amount is not enough, specific user does not exists, you must do it in DAL, or use stored procedure for it.

But, any validation in DAL, must be called from BL and avoid direct call from UI.

Answer 2

You should check it twice.

Once in the BL to show the user a normal message says he entered an already existing value.

For the second time, you should check in your DAL that you're not trying to insert a unique value (just like a UNIQUE CONSTRAINT does in the database) because you don't know who will use it, in such case throw a custom exception that can be understood by someone new that uses you're DAL layer.

Answer 3

I am of the opinion that playing ultra safe is stifling. Do the dupe check only in BL and bring the entire list of objects through a dal call. However if the list of objects is too huge you may have to dothe dupecheck in the stored procedure/DAL layer