There is a lot of question about the correct architecture to use for a data layer.  Should you use strongly-typed datasets?  Should you custom code your DAL?  Should you use Data Transfer Objects to pass the data back and forth?  There are pros/cons to each.  Strongly-typed datasets seem to have a lot of support with developers, mainly because they are easy to use and setup.  They create strongly-typed DataTable/DataRow objects that are all a part of the designer-generated code.

Alternatively, DAL code could return a DataTable, DataSet, or a data transfer object.  This is another source of argument, as to which is the best approach.  Data Transfer Objects require a coding effort for each data source, but they do provide strong typing and some conversion capabilities, similar to the strongly-typed dataset.

DataSet (weakly-typed) and DataTable objects are disconnected representations of the data that are easily and widely usable in application development.  They aren't strongly-typed, meaning that you have to reference them in the collection by name or index of the table/column/cell.  A DataSet is comprised of one or more DataTable classes, and a DataTable is comprised of one or more DataColumn and DataRow classes.

Each of these has their own drawback.  Strongly-typed datasets can have some configuration problems that people experience, especially in determining whether a field can or cannot be null, and how nulls have handled (this may be a minor problem.)  In addition, some people like to have control over their data layer, and because of this like to custom develop it, instead of using the designer approach.  In addition, a strongly-typed dataset returns all of the data for a specific table, which is not always desired.

Data Transfer Objects do require an additional coding effort, which adds to the total time that it takes to develop an application.  It's strongly-typed, which means that it provides an interface for the data source; however, any changes to the data source requires work done to the data transfer object.

DataSets and DataTables are widely used classes since they represent data from a database, can read XML, or can be returned by an XML Web Services.  However, they aren't strongly typed, which means that you have to reference by column name, and thus maintenance of a column name change could be difficult to make.  Another alternative exists, which is the use of a third-party framework, but I'm not going to touch upon that.

When determining your architecture, a strongly-typed dataset is the least amount of work, a data transfer object approach is the most amount of work, and weakly-typed DataSets/DataTables are in-between.  There are other considerations to take into consideration as well.  Will this API be used for a web service?  Will it be used as a data contract in a WCF service?  Will it be used to bind to an ASP.NET web page?  Will these objects control the interaction within the application directly?  What will all of that have to do with the data?  These are all factors you have to take into consideration with your architecture.

Between the data layer to the business layer, some action on the data takes place.  In some situations, the data is passed directly, such as passing a DataTable or strongly-typed dataset directly back through the business layer to the caller.  In other situations, the data layer returns a data object to the business layer, and some conversion takes place.  This is another factor to take into account when designing the back-end architecture.

Generally, it seems that application development systems have been heading for creating a business architecture using domain-driven design and business objects.  The value of an API that controls your application is very popular, especially in the realm of windows applications, such as the Microsoft Office platform.