Validation logic, security and the web

I just read a blog post by Rocky Lhotka where he discusses where to put the validation logic. This interests me quite a bit because it's one of those caveats I've found around ASP.NET and web development in general.

The problem with validation in a web environment
In web projects you often want validation to take place on the client (to reduce the number of post backs and give a better user experience), but it's not an environment you can trust.

How not to do validation
For obvious reasons, as stated above, you should not exclusively put validation on the client.

One way of solving it
I would agree with Rocky Lhotka that you should put validation in the business layer to begin with, and then duplicate that to the frontend to give the user a better experience. The main point here is that the business layer will be the deciding factor what gets though no matter if the UI validation isn't working as it's intended to.

Preparing for the future
Another important point Rocky touches on is that the UI is more frequently replaced than the business layer code, which gives some value to having the validation there no matter if it's implemented in the UI.

Security
One good rule I've come across is that you should treat everything coming from the user as potentially dangerous, and even better, do the same for anything that comes from the database. With this in mind, putting at least the critical validation in the business layer seems like a good idea.

Patterns and practices?
I'm looking into ways of building robust applications by using the MVP pattern (supervising controller) and TDD. I'll probably write more about that when I've gotten a bit more experience on the subject.

Weeks of .NET

This last month have been spent coding in .NET (mostly VB.NET) at my full time practice at Avancit AB. I thought I would share a few things I've come across in the projects I've been working on during that time.

T-SQL
I had a problem where I needed to get all mail addresses of all groups in a company except those in the current group. This was solved by the SP shown below:

ALTER PROCEDURE [dbo].[sp_GetMailAddressesByCompany]
(
 @intCompID INT,
 @excludeGroupID INT
)
AS
BEGIN
 — Get all addresses in company that are NOT in the excluded group
 SELECT addr.* FROM tblMailAddresses addr
  INNER JOIN tblMailGroupsToAddresses con
  ON con.intMailAddressID = addr.intMailAddressID
  WHERE addr.intCompID = @intCompID
  AND addr.intMailAddressID NOT IN
  (
   — Get all addresses in the excluded group
   SELECT addr.intMailAddressID FROM tblMailAddresses addr
    JOIN tblMailGroupsToAddresses con
    ON con.intMailAddressID = addr.intMailAddressID
    WHERE con.intMailGroupID = @excludeGroupID
  )      
END

BCP versus SqlBulkCopy
Another problem was where we had an application that needed to push tables from a client to a server effectively. The current version at the time used BCP which was run from a batch process and sometimes (but very rarely) failed.

I started to look around and I found that people where replacing BCP with SQLBulkLoad. I suggested we'd try it and we successfully implemented the transfer using it. As the whole process now took place inside the .NET application it was simple to setup a better error handling than was possible with BCP.

Macros
As for productivity, I've started to look into using macros in VS2005. The first macro I installed was one that reversed assignments. I know there are tools that do this, I think ReSharper has this ability, but I don't have it yet so a macro works just as good. You can find this macro at: http://www.codeproject.com/useritems/macroswapassignments.asp

DNR
Anyone still not listening to DotNetRocks are missing some great stuff. As I'm on a train or a bus for 3 hours a day I've listened to quite a few episodes in the last few weeks (1 to 40). Even the early episodes are great, they give a good insight into why things are the way they are and what is new in .NET 2.0 (as I started with 2.0, I don't have much of a reference as to the differences compared to 1.1).

TDD
Next week we're starting a project that will use TDD (Test Driven Development) for the first time within Avancit. It will be lots of fun and I'll probably write how that goes here later.