Pass Generics and Classes between Layers, Methods, and Services
Generally, generics, arrays, simple datatypes (e.g., strings, integers, etc.), and class objects are preferred over typed or untyped datasets when transferring data between layers, methods, and services in Windows or Web form applications. Since most .NET application development is in a transitional state moving from OOP MVC to an SOA architecture, the typed and untyped dataset is too bloated and proprietary for service communication objects in large applications with many users such as ARTS.
Datasets always serialize themselves as XML, which have bandwidth and performance implications when passed across service communication boundaries. The alternative to using datasets is to create custom object types that represent business entities, and custom collection types to contain them. Even though this route may result in more code, the bandwidth requirements are much lower since serialized objects are not nearly as verbose as datasets. Custom objects have the advantage of allowing explicit and complete control over the way the type is designed and what its internal capabilities are.
When designing a layered system the programmer must consider factors such as the ability to cascade changes (such as new data schemas) through layers and the amount of overhead involved when data is moved from one layer to the next. Plus the programmer will need a business tier to execute business logic, and he or she will need a DAL to provide Create/Read/Update/Delete (CRUD) functions to the rest of the system. Using custom business objects results in a far more elegant and neat solution where data is perfectly modeled on the domain of the problem. Maintenance and extensions are greatly facilitated, readability is assured, and technical documentation is easier with generics, arrays, simple datatypes, and especially class objects.