When working with the 3-layer model, where should the validation code be placed? for: not empty fields, unchecked options, null values, wrong-written dates, etc.

To keep total isolation between a form (UI layer) and the business rules, this validation should belong to BLL?

It's the only work for the UI: grab user data input, without any care of verifying, and just send it to next layer.
For example, It's an empty username field, really breaking a business rule, or the BLL doesn't even need to care about getting empty values, sure, UI takes care.

Could be this shallow validation, considered as an actual BL rule, or is enough handle it on UI layer?

  • Can the UI layer be trusted? If you validate too early, what are the implications on the logic of your application? (Will it cause a critical failure? Security leak? Or just harmless?)
    – Rufflewind
    Aug 17, 2014 at 0:35
  • That's my question, is the UI a proper choice for this validation?, is better to take care of an empty but requiered field here, or just sent to BLL?
    – Shin
    Aug 17, 2014 at 9:40

2 Answers 2


As encountered on multiple websites where it is asked to fill-in a form, you often see obligatory fields. Such fields are often validated through Javascript for non-emptyness and all-numeric inputs, for instance.

Yes, it is better to have the back-end do the dirty job, but the UI makes sure that the information input is provided, then the input is further validated in the back-end code.


In an MVC application, you'll have the view validates for obligatory empty fields and the UI shall not allow for blank input into obligatory fields. Then, once the mandatory information is provided, it belongs to the controller to send along the information to the model for proper validation.

For more information on the MVC architecture pattern, you may pay a visit to Martin Fowler's website on the topic.


In an MVP application, you'll have the two approaches: Supervising Controller and Passive View.

Supervising Controller

The view is aware of certain rules such as enabling a button once all required fields have been filled in properly. Even for format validation! For instance, your view shall present proper controls for different inputs such as a drop-down calendar, a combo-box, a numeric-up-down, etc. Then, it makes sure to enable the submit button only and only if all required information is filled in.

Passive View

The view is a dumb. It all passes on the information right to the Presenter which validates in the back-end whether the information is good or not. It's easy to setup such a Passive View pattern in Windows Forms application or the like, but clearly misleading (IMHO) in a web application.


The view and the view-model are bound together so that the view-model may state whether it's all required fields have been filled in correctly and act upon the view accordingly. Besides, it is far more preferable, to my point of view, to let the view the possibility, for example, to whether enable a button when the information in itself changes, based on the view-model state. That is the view that reads the view-model state, and the view-model shall then tell the view whether the button shall be enabled or not.

There are also more architecture patterns which handles different things differently. They all have their benefits and trade-offs. MVVM is great for WPF application, and MVP is best for Webforms application, as MVC is best for Web application in general. You may even prefer to use a hybrid approach such as MVP-C-VM, etc. based on your knowledge and expertise. The idea is to keep the code as simple as it can, and easy to maintain as it can. So basically, it is finally quite a matter of preference based on your expertise and experience.

In the end, as far as I'm concerned, I like best to have some basic validations directly in the view (UI-layer) to offer a better user experience and avoid some lags that can occur with the back-end. Then, when the user actually submits the information, a more robust validation can occur.

  • If we're talking about keep code as simple and easy to maintain, I think basic validations such as empty fields, etc. would better be handled by back-ends, with all the other ones (business). However you have a very good point, with possible slow response times to UI layers.
    – Shin
    Aug 17, 2014 at 18:35

It depends on what your requirements are, but for maximum robustness validation at the backend is preferred, but that does not preclude validation in the frontend as well.

  1. Do you care if bad input gets into the system? Will it wreak havoc? If so then you definitely should validate in the backend, unless you are absolutely sure that there's no way for the bad input to sneak past the frontend validations.

  2. What feedback will the user receive if validation fails? Inevitably, in order to construct helpful error messages your user interface will need to have some knowledge of what's wrong with the input unless your users are okay a generic "ERROR: BAD INPUT". Now, you probably won't need to duplicate the full logic here if you design it well, but this also depends on how much assistance you want to give to the user.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.