Let's talk about class design. It's very interesting to see what Microsoft recommends to us, the developers. If you've worked with the IBuySpy portal or store, then you will know what I mean.

C# and VB.NET are both .NET languages that emphasize good object design using consistent design patterns whenever possible. Microsoft worked hard to get VB.NET to become an OO language too, but what Microsoft recommends for a web application is a little different.

IbuySpy, which Microsoft calls "a collection of best practices" for a .NET web application has a class design that doesn't really follow the Object Oriented approach. IBuySpy has only one Middle Tier, which combines BLL and DAL. That middle tier consists of relatively thin engine classes that only wrap SQL Server stored procedures.

Although some people say IBuySpy has a very bad design, in my opinion it’s a great design. It's very fast (due to a minimal number of roundtrips to the database) and its complexity is reduced considerably by combining the BLL with the DAL. If you are designing a Content Management System or something of the like, then this is the best way to do it.

You can develop these applications quickly too. Though, one place where this falls down on is in its code elegance, hence it's harder to extend or modify the application in the future. It is designed like a procedural program; with functions not object oriented programming with objects and methods. When you try to upgrade or add functionality to these applications you will have a hard time understanding the application.

So, if you are designing a huge enterprise solution, this definitely isn't the way to go. Also, if you have more than one type of client, for example, if your business tier feeds data to both WinForms and WebForms, then you might want to consider a different design. This is especially the case for WinForms, as passing a DataReader through the network isn't such a good idea as a connection is opened during that transfer. Use a dataset or custom collection for this instead!

So what are the alternatives? I think there are many good alternatives, but a collection / class design is the best one in my opinion.

Basically, each entity consists of two classes. One is the entity (e.g. User), and one is the entity collection (e.g. UserCollection or Users). An entity class contains properties that describe the entity (e.g. Name, Email), as well as methods to update the data. A collection class is ultimately a child of an ArrayList class. It will have methods to fill up the collection (e.g. GetAllUsers, GetAdministrators, GetRandomUsers), enumerate through the collection (eg MoveNext, Current, Reset), delete an entity, and finally add an entity.

By using this design, your source code will be much easier to understand and modify in the future. One disadvantage of this is that the performance is compromised due to having more objects and round trips to the database.

This design is good for business tiers feeding data to multiple types of clients -- e.g. WinForms and WebForms -- because it uses a disconnected data model, much like typed datasets but a little lighter in features and far superior in performance. You can even pass it through the network without holding the connection to the database.

I use this design for relatively large web sites or solutions that need support for multiple client types.