Software Engineering
design architecture validation layers
Updated Mon, 23 May 2022 12:17:15 GMT

Where should the "not empty field" validation code be written on a 3-layer application?


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?




Solution

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.

MVC

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.

MVP

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.

MVVM

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.





Comments (1)

  • +0 – 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. — Aug 17, 2014 at 18:35