Finally, ASP.NET validation the way it should be

Finally validation in the business logic, not the UI.

One of my biggest frustrations with ASP.NET all along has been that implementing simple validation and even complex validation has always been in the UI layer. Of course the validation must be presented using the UI layer, however the UI should not be determining what validators should or should not be used. This should be the responsibility of the business layer.

The database defines some of this business logic implicitly as well. For example, datatype, maximum field lengths, and numeric ranges (based on data type), required field or optional (nullable). This is necessary as these are rules that are both business rules and data rules.

In my mind, all validation should bubble up from a lower layer to a higher layer. The lowest layer being the database, then the data access layer, business layer (including business entities), and finally UI. If the logic is available at a lower layer it should be the default for higher layers.

There is validation that should not require much effort of the developer, but are also required on nearly every application I have ever written. These include at least the data rules. What this means is that if the database shows that the OrderDate column is required and is of datatype DateTime the developer should not have to hand code this validation logic. It should be something that is a given. It is a waste of time, a maintenance issue, and in general just not something that should have to be worried once it is defined in the database.

There is above that information that we know as the designer of the system that the database doesn't know. This is basically metadata. For example, it could be that the OrderDate is actually only a date field, not time information is important. In the database both are always stored, but we don't always care about both. We also may want to specify a format for the date to be used everywhere. We should be able to specify metadata about our columns that quickly and easily describes these attributes.

Custom validation on a particular column is also needed sometimes. Sometimes external sources need to be checked to determine the validity of a value. Or maybe it depends on user permissions, etc. In this case, it is important to be able to write this custom logic at the column (field) level, not in the UI. Ideally, it would be in the entity that represents that table. Any validation error should bubble up to the UI in this case as well.

Custom validation on multiple columns is also sometimes needed.  For example, maybe you want to be able to require that the StartDate is before the EndDate. Again, this should bubble up to the UI.

One final layer that should just know what to do is the UI. The UI is responsible for presenting this validation to the end user. We should be able to specify in one place that by default all datetime fields should use a Calendar control for example. Why should we have to rewrite and make that decision over and over again throughout the application. Again, if we change our mind in the future, this should be done in a single place, not everywhere we used the calendar in the UI.

What I have described to you is what I have been wanted from day one with ASP.NET. WebObjects (from the Java world) gave me this way back in 1996. Finally, ASP.NET has caught up, and done an excellent job of implementing it. The technologies you want to look at are ADO.NET Entity Framework and LINQ to SQL Framework. They both have what is needed to be the data and business layers. ADO.NET Entity Framework is a lot more flexible by not requiring direct 1-to-1 mapping of entity to table, is serializable, and still can be used with LINQ using LINQ to Entities. Even when you use both of those, the UI is still the problem because you have to keep it in sync. ASP.NET has the answer Dynamic Data to the rescue. You can use Dynamic Data to have the UI behave as I described throughout this discussion.

Now that you understand why these technologies are so cool here are some links to my blog entries that tackle some of these issues.

• Simple, but robust business logic using ADO.NET Entity Framework