Good day.

I am currently designin the architecture for a new, rather large application. I am making it N-Layered with late-binding approach for plugins, dependency injection for data layer and so on.

The architecture could be summarized in DataBase -> DataLayer(s) -> Business Layer -> Application Layer(s) ------ All using a Common layer containing POCO classes, Facade interfaces and so on.

For business entity validation (POCO objects) I am using Microsoft Application Blocks.

A co-worker pointed out that the windows forms controls he will be using for the user interface have "validation" properties integrated, like a regular expression, etc.

I told him that we can't use those properties, as the whole validation must be set in the Business Layer and consumed from the application layer. Defining the validation rules in the application layer is not only a design error, but it can lead to poor mantenaibility of the application (duplicate rules, sync problems, etc).

He then asked why third-party companies make components like those if we cannot use the integrated validation properties. I guessed that those controls aren't made for N-Layered architectures, but more likely for small apps and RAD.

I wanted to ask what you guys think about it. Am I right, or I am missing something important?

Thanks.

I think you are both right: javascript is used in the user interface (optional) and you also need validation in the code behind (mandatory).

Edit: may be out of subject because you are talking about windows forms?

Well, windows forms or web, it shouldn't matter: for web (I use MVC) the JS validation is a good thing, but the JS code shouldn't contain the validation logic: it should instead use an AJAX call to query the business layer, validate the data and get the ok/error, then display it.

My point is, am I right considering those controls something not thought for N-Layer development?

Sgro:

My point is, am I right considering those controls something not thought for N-Layer development?

Hmm... not really. It's a different kind of context. The purpose of the validation controls is not to provide business rule validation or even property validation, it's only about form input validation. Indeed, validation rules are (usually) a concern for the business layer, but if the user interface can be given instructions to help the visualization/first step validation of these rules, then all the better. That's where the validator controls come into the picture in n-layer development. Not as "validation rule enforcers", but rather as "validation rule presenters".

Many, if not most, validation frameworks for .NET offer some kind of attribute based rules. If the presentation layer has access to the real business entitiy classes, then it can also read those attributes and add corresponding validator controls to the form/page. The PropertyProxyValidator from ELVB does exactly that.

Of course, final validation should always be done in the business layer, but why not avoid a couple of server roundtrips (postbacks or ajax calls) on the way there..

That's an interesting point of view indeed. But does it still hold true when our application has multiple application layers? I mean, we're going to develop a winforms interface, a mobile interface and a web interface.

Doesn't using control integrated validation create some sync problems? I mean, If I change some validation rules, I have to go manually change them in every application layer, with the risk of forgetting something and having different validation on the same object/property on different user interfaces.

Sgro:

That's an interesting point of view indeed. But does it still hold true when our application has multiple application layers? I mean, we're going to develop a winforms interface, a mobile interface and a web interface.

Absolutely! The beauty of declarative (attribute/metadata/configuration/xml based) validation rules is that they can be discovered by any kind of user interface. 

Sgro:

Doesn't using control integrated validation create some sync problems? I mean, If I change some validation rules, I have to go manually change them in every application layer

If you change the rules, the controls will adapt to it automatically. If you set things up correctly, that is.

http://www.pnpguidance.net/News/ValidationApplicationBlockPropertyProxyValidatorScreencast.aspx

 You could always place of your validation and business rules into a separate assembly and share it between the layers? Something like..

 // In the business layer
    public class Customer
    {
        // ....

        public List<BrokenValidationRule> Validate(ICustomerValidator customerValidator)
        {
            return customerValidator.Validate(this);
        }
    }

Then all you would need to do is use the same validator in the presentation layer something like this..

protected void submitButton_Click(object sender, EventArgs e)
        {
            ICustomerValidator customerValidator = new CustomerValidator();

            if (!customerValidator.Validate("Name", txtCusomerName.Text))
            {
                // not ok...   
            }
            else
            { 
                //....
            }
        }

Just an idea.

Cheers
Scott

Well Scott, that's exactly how I am doing it, and what I am trying to have my co-worker understand. I DO have validation in the business layer, and intend to call it from the various application layers.

If you want to settle your argument, you are correct. Validation should be handled by the business layer, and using controls only is a big no-no. But that shouldn't stop you from using them. They are controls designed to improve the user experience, but they have no more business relevance than the border around a checkbox.

Hi

I also agree with what other members have said regarding the usage of those validation controls.With my two years of experience in asp.net development I havent used those controls and most of my validation I have handled either through client side javascript code or by making use of bussiness layer(for bussiness validation).Infact I remember in one my projects someone used the "Create User Wizard" for creating CreateUser screen.I must tell you later on we were in such big mess that finally we had to redeisgn everything with pure asp.net server controls and making use MemberShip api behind the scene for other plumbing work.

Even in an N-layered architecture, it seems to me that you should approach validation just as you would any function, in an OO manner.  Each object should know how to validate itself, perhaps based on rules presented to it at some stage.  Low-level objects won't know about other objects or combinations of objects, so their validation should happen at the next layer up, which does know.  In your case, that would be the BLL.

As far as UI elements, in what sense can a text box validate its own content?  Maybe against a RegEx, but certainly not that it contains a valid part number, or something like that.

Client-side validation can be approached in a similar fashion...