4 Teirs to build the app...

and 1 data access component (dac) to rule them all, 1 dac to find them, 1 dac to bring them all and in the darkness bind them.  In the land of SQL Server, where the Yukon lies.

Tim Rayburn
with apologies to J.R.R. Tolkein

I've spent some time over the last several days reviewing some of the “best practices” which I've developed for Visual Basic 6 in the light of the Visual Basic.NET and the .NET Framework in general.  Here are some of the thoughts I am having:

1. Data Access Components - Several times over the years I've heard the arguement for a data access model which has 1 component to handle running SQL against an RDBMS, with project components developed which reference that component and offer up that data to the “business objects”.  The problem has been that recordsets just are not meant to handle that type of environment.  But ADO.NET on the other hand, seems to have this taken care of, in spades.  This model is nearly perfect for the world of .NET, as you right a singular class to work with the most efficient DataAdapter for your RDBMS.  Then your project specific data access components are written to use schema'd datasets, which will ease the development of the business objects.
2. Gone are the days, of Option Explicit - Option Strict is the only reasonable way to go.  Yes, VB developers will need to learn how to actually declare variables of they type you need, but it also can get rid of alot of 'mystery' bugs arising from assigning a Long into a Variant when you expect it to be a String, etc.
3. Likewise gone is On Error - Try ... Catch ... Finally.  Say it three times, it's just not that hard.  I know, I can hear the real world developers whining about having perfected their cleanup routines to use On Error and how well it is serving them.  Have you looked at the glory which is Try ...Catch ... Catch ... Catch ... Catch ... Finally?  I'll post some examples of this next week.   Error checking will never be the same.
4. Web Services - I know Microsoft is trying to 'down talk' web services because it frightens people out there who are simply doing Client/Server apps, etc.  Trust me when I say this, every Class you right should implement itself as a Web Service as well.  Why?  Because you might just need it eventually.  Because when your boss asks if you could allow him to interface with your application from his PDA or cell-phone, you'll just smile and say, “Of course, we'll just develop another presentation layer for them.” And you won't be lieing through your teeth when you do.

Hardly a complete list, but it is some initial thoughts.