Where do we need to include non business logic validations in Service Layer

Currently um working in an application and it has the following hierarchy

WEB API2 Controllers (hilds the end points)

Business Logic Layer (Dedicated for business logic handling )

Data Access Layer (Repositories)

If we want to impose a validation which does not related to a business logic as for an example a character count validation for a specific field in an entity , what will be the ideal place to implement it?

Some says it should be on Controller it self , but I cannot agree with it .


There are no hard and fast rules. But usual place to implement is in the business logic layer. Also I think that field size validations are business logic.

If you use a rich domain model you should implement validation in the entities. But if you don’t have a rich domain model and the only interface you provide to the outside world is via your web API I don’t think there is anything wrong with doing validations there.

If there is a front-end app I would duplicate the validation logic there as well to give better UX and save the network call.

I think that always depends, I know that DRY (Don’t Repeat Yourself) rule is very strong and powerful, but at any price?
There is also another rule “fail fast”

If the validation is really simple (as checking a string is empty or less than X characters) then I don’t think is a harm to check it in different places.
Also there exist the rule “fail fast”, so why to continue spending time in our CPU, eventually connections, memory, etc…

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *