Best place to enforce Business Rules and constraints on Data attributes

Recently as part of the activity of making our application more stable and improve performance, we were trying to find out the best possible place to enforce few of the basic business constraints on the various attributes. Having such constraints and validation is very much needed to have stable application and keeping data consistency.

To my view , there are 3 places where such constraint check can be tried.

Entry point — One can verify that the data entered in to the application has the correct format and value by having validation at the UI layer itself.

Application Layer — Checks can also be applied at the application level to make sure that its verified before it gets processed for any workflow.

DB Level — Many such constraints can be applied at DB level by exploiting constraints, null able properties, checks and triggers before the data get stored into the DB.

Now what is the right place to do it? do we need to verify at multiple levels?

To get the answer to the question above, let’s take an example of an application which require a registration mandatorily. As part of the registration, email is being used as user name and need to be provided compulsory.

In this case, we may decide to do the validation of mail ID at entry level. At a UI level, when any one getting registered, email ID is getting checked before a call is made to application logic at backend. We may not do the validation at the application level as it was already getting performed at UI level. Many applications do such mistake Why?

Let’s think of a new requirement where you also start allowing registration through an API call so that external tools and application can be registered programmatically. Now as UI validation is no more applicable, we are caught red handed. No application level validation means empty or NULL value can be registered. So we need to start looking at best place of validation again, and this time we decided to do the validation at the application level too. Are we fine now?, I don’t think so.

With some time pass by, and you came up with a new version of the application. This version exploits some new ways or building application (may be micro service based or just supporting the application on cloud now), and you need to migrate old customers to new version and require some data movement too. Most of such migration require data to be moved from old schema to new schema or from one location to another location (in cloud). While moving so we may have to make sure that data remain consistent and all the business constraints are enforced always. For example, email address which was compulsory in our application, we need to make sure that we don’t enter null by any mistake of migration script bug. So such cases mean that wherever possible such business constraints should also reflect in our DB level too so that any such migration and manual entry are correct too.

OK, how about keeping the constraints only at DB level and removing UI and application level logic?

While this may work, we are moving the validation too late in the cycle and a wrong data entry will unnecessary put load on both application server and DB server and may start hitting performance.

Ok so what about the combination of any 2?

I feel UI and DB level constraints can suffice in many cases until, unless application has some logic and workflows which does not require any DB access. In this case we are only end up having validation only at UI level, which in some case is prone to hacking. Java script change and injection is very normal in hacking practices and it’s quite possible to skip/bypass UI level validation using the same, which mean application may start behaving incorrectly as it starts getting data without any validation.

So I feel if performance is not getting impacted much and data consistency is a must requirement, validation is needed at all the 3 levels and should be implemented to have very stable code base and avoid any data inconsistency.

Feel free to provide your input and view on the same.