The standard ASP.NET validator controls such as the RequiredFieldValidator or the RegularExpressionValidator do not cover all validation requirements, so usually developers tend to create a CustomValidator for such scenarios.
A major problem with the CustomValidator is reusability, as if you wanted to use the validator in another project then there would be some copying and pasting and code duplication, then you have to maintain multiple versions of the same control.
The solution, as you have guessed from the title, is to build your own validator control when possible to promote reusability.
In this post I will be showing you in three simple steps how to build an ASP.NET validator control and take credit card number format check to show by example. I will also be building the architecture so that your validator and other validators that you will develop in the future could be as reusable as possible.
How to Check a Credit Card Format
Luhn check is an algorithm that checks if a credit card number is valid (format wise), so in practice, before you even think of doing any further processing on the credit card, this check should be satisfied.
Search engines optimisation, SEO, is an evolving ‘science’ and it keeps changing on purpose. Most articles that I read which involve both SEO and ASP.NET usually focus on how to programatically set the meta keywords tag and they tend to make it look like very important while, as of today, it has minimal effect on optimisation.
Generally, web developers tend to turn the blind eye when it comes to SEO while a great part of SEO should be done by developers. Here are three rules for .NET developers to follow while building a site:
Visual Studio 2008 is a huge resources consumer, it takes long to load then long to open your solution, long to run it and debug it. I have been using it for more than a year now after setting VS 2005 to retirement. I have VS 2008 set on a high perforamce Vista Business laptop with 2GB of memory.
While working with ASP.NET on VS 2008 my colleagues and myself started to notice some patterns when running or debugging a web project that will improve performance rapidally. Tricks that do really work and we laugh every time they work at how silly they are.
Here are two interesting tips that we encountered:
In the pre-LINQ days, I used to use the classical 3-tiers architecture for designing ASP.NET web projects, the user interface (UI), the business logic layer (BLL) and the data access layer (DAL).
My DAL layer used to rely on Microsoft’s Data Access Application Block (DAAB) which abstracted the repetitive and boring ADO.NET implementations. There are some 3rd party tools such as SubSonic, which has some common features with LINQ, or NHibernate, however, I would rather use the enterprise library.
Let me quickly illustrate the way to solve a problem with the classical architecture. This is a simple business problem, a website that has many brands and each brand has an advertising campaign. To access the campaign stats, which are supplied by the campaign agency, we need to access the agency’s webservice by providing our brand credentials. We simply store these login credentials in our database -> retrieve login info of a brand -> call the webservice -> display the stats on a web page.