Passing Data Between Layers and/or Tiers

  • Article

 While  we were commenting some high-level strategies for data-access in a previous article, we mentioned a popular pattern used to interchange information between layers or tiers. We are talking about the Data Transfer Object (DTO) pattern. As the MS Patterns & Practices' book "Enterprise Solution Patterns" states, this solution strategy helps to reach

  • Reduced number of remote calls
  • Improved performance
  • Hidden internals
  • Discovery of business objects
  • Testability

But, because nothing is for free in this life, at a cost of

  • Possible class explosion
  • Additional computation
  • Aditional codding effort

Is there any way to mitigate the risks, while still reaching its benefits? The .NET platform answers this fundamental question with Typed-DataSets: collections of custom classes backed as ADO.NET's DataSets. Technically speaking, Typed-DataSets are extended DataSets ready to work specifically with a specific type, being able to validate we aren't using anything but such type in compile-time

So, what we usually express like this, working with ordinary, untyped DataSets

//-- Untyped DataSet
string sCoName =
    oDs.Tables["Customers"].Rows[0]["CompanyName"].ToString();

We can abbreviate and validate against the DB schema at compile-time with typed DataSets with a sentence like

//-- Strongly typed DataSet
string sCoName = oDs.Customers[0].CompanyName; 

As you can see, there's no need to lookup tables, because a typed-dataset's called Customers is actually a table; there's no need to explicitly access Rows or Columns through indexers, because we have available properties (like CompanyName in the above example) with the same name and type as DB table columns

Because they are DataSets, typical features like filtering, sorting, searching and other powerful DataSet capabilities are still available at no charge. But best of all, Visual Studio 2005 provides facilities for creating Typed-DataSets directly from DB tables, just by dragging and dropping them from the Server Explorer

Furthermore, Visual Studio 2005 creates for us a Table Adapter: a Data-Access layer component which moves data back and force between the Data Tier (i.e. the Database) and the Typed-DataSet. There are TONS of coding time saved because Visual Studio 2005 generates, by default, basic CRUD (for Create-Retrieve-Update-Delete) methods when generating the Table Adapter for us. We can, in turn, add our own specific data-access methods like GetCustomersByProvinceId(), etc

For those who believes I could be exagerating a little, I would like to invite them to watch Brian Noyes's webcast "Implementing a Data Access Layer with the Visual Studio 2005 Dataset Designer". Brian, solution architect from IDesign, is a MS Regional Director, author of several books and magazine articles on .NET applications

I also recommend the MS Patterns & Practices' "Enterprise Solution Patterns" chapter called Implementing Data Transfer Object in .NET with a Typed DataSet

Enjoy it!