Design Architecture – Where to Write ‘Not Empty Field’ Validation Code in a 3-Layer Application

Architecturedesignlayersvalidation

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?

Best Answer

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.

Related Solutions

Dependency Injection – Abstract Factory Patterns in C#

It seems you're struggling trying to create objects that create objects... wouldn't you be better off just creating objects ?

Ninject allows you to do so in a very simple way :

// Ninject module
Bind<IRepository<SomeEntity>>().To<SomeEntityRepository>();

// injected class
public class SomeService
{
  public SomeService(IRepository<SomeEntity> repository)
  {
    // ...
  }
}

// get instance of injected class
var someService = kernel.Get<SomeService>();

I can't see the benefit of an abstract factory in addition to an IoC container when you're creating objects based on basic, compile-time-known constraints such as in your SomeViewFactory and SomeRepositoryFactory examples.

The dynamic nature of SomeFunctionalityFactory would be more debatable, but when you think of it, do you really need to instantiate an object with the built-in notion that it will never be able to be used by the current user ? Wouldn't it make more sense to have the object evaluate user authorization when the functionality is called ?

Domain-Driven Design – Validating Domain Model Rules with Database Content

How complex are the validations? Often validations require a combination of fields and or business rules that rely on fields to be accurately evaluated.

The more complex the validations, the harder and less performant option #2 is.

Of course the data tier could invoke the validation service at persistence time. This could help the odd situation where data is in an invalid state due to a change in rules.

The other item worth commenting on is the ability for a change in validation rules without a qa cycle of some sort. But that is a topic for a different thread.

Given the information above, option 1 seems the most flexible assuming you maintain discipline, separating validation and persistence.

Best Answer

Related Solutions

Dependency Injection – Abstract Factory Patterns in C#

Domain-Driven Design – Validating Domain Model Rules with Database Content

Related Topic