DbClass is a software AntiPattern.

A developer creates a class that has methods that are passed the name of a stored procedure or a sql statement and an array of parameters.  The methods generally return data tables or scalar values or data sets.

Here is an example of a call to such a method:

 Data''''''Table customers = DB.Get''''''Table("dbo.Get''''''Customers", params);

Where "dbo.Get''''''Customers" is the name of a stored procedure and "params" is a database parameter array.

What's wrong with this pattern is that the calling code has to know the structure of the database - name of stored procedure, names and types of the parameters.  A true Data Access Layer hides the database from the other parts of the application.

I've seen this DbClass AntiPattern used in two ways:

* The methods are called directly from all over the place.  For example, in the code-behind of an aspx page or in an event handler of a Windows Form.
* The methods are called by a "data access layer".  For example, in the code-behind a call is made to a method in a data access class, then the data access class makes the call to DB.

The 1st way exposes the database structure to the harsh light of day - not a good idea.  Try to make some database changes or change the parameters of a stored procedure and you will be doing text searches and endless regression testing to make sure you didn't break something.

The 2nd way is not as bad, at least the stored procedure and the parameters are hidden from the UI code but these methods return generic Data''''''Table objects and then the code that made the call has to know the names of the table columns, which brings us back to the same issue as before - code outside the data access layer has to know the database structure.

If you really have to use Data''''''Sets and Data''''''Tables for passing your data around then use Typed Data''''''Sets (.NET) or their equivalent in the language of your choice.  

Better still is to use a DomainModel pattern and an ORM tool that converts data from a database into objects and collections of objects.  NHibernate, LLBLGen and now Entity Framework are just three of the many choices available.