Scott Hanselman posted a good reminder on multi-layered/tiered design. If you have already read it, read it again and live it. If you haven't read it yet, then shame on you for not subscribing to Scott - and you call yourself a .NET developer?! Go read it.

When I am training developers I find that I spend more and more time on this topic. I find that it is not something that is emphasized in schools and often not understood by new developers. I am big supporter of layered architecture and just love to see a good multi-layered design. I can't tell you how bad I hate to see the use of System.Data.SqlClient/OleDb or even System.Data in the presentation layer. There's a place for that stuff and it is definitely not there. If this is a new topic for you - don't go to sleep again until you get it. Once the reasons why a layered/tiered design is such a big deal “click” for you, you'll never go back to your former bad practices. Pure bliss.

But it's not so much of just knowing how to design a multi-layered application. It is much different to really understand it - so that it just comes out natually in your designs. It takes experience, but it is not an unattainable level of experience. Make it a point to properly design your applications. Any application, no matter how small. As far as the argument goes that it will increase the duration of your design and development phases. Well, it might at first. However, the payoff is huge and once you start to understand it you'll have a hard time thinking about your designs any other way.

Also, since this tends to be a part of the area of confusion that new developers have at times, I wanted to pass along a quote that Ken Robertson left in the comments on Scott's post: “hardware architecture does not determine software architecture, code does”.

BTW, while you are at it, follow-up with reading Scott's post on why you should be returning domain objects from your web services instead of DataSets. Working with domain objects, whether from web services or elsewhere, makes for more concise and natural code. Why work with a “bowl” when what you really want is the “apple”? Take a look at my previous post on returning objects from web services for more info.