Using Strongly Typed Objects and Collections to replace DataSet’s in your .NET applications.
page 1 of 4
Published: 01 May 2004
Unedited - Community Contributed
Abstract
This piece discusses the advantages of using Strongly Typed objects in your applications - this method of coding can save you hundreds of hours if implemented properly.
by Phil Winstanley
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 37168/ 60

Reasons for the Switch

Indexers, are one of the ugliest methods of accessing Data stored in objects, they do not lend them selves to the eye, and using DataSet’s you will find yourself using the indexers a lot, below is a line of code showing the use of Indexers in a DataSet.

string myFooRegistration = myDataSet.Tables[0].Rows[1][2].ToString();

The above does not seem particularly elegant in comparison to a Strongly typed object such as the one shown below which only exhibits one indexer to achieve the same: -

string myFooRegistration = Foos[1].Registration;      

In the same vein, it is possible to make your Collection Indexer’s even more Developer friendly by using Strings or any other Data Type as your indexing identifier, for example below a string (Foo Registration) is used as the indexer: -

string myFooRegistration = Foos[“DMN 666”].RegistrationDate;      

Weakly Typed fields in DataSet’s lead to confusion and can very easily end up with people using the wrong Type for the Data that is being represented. It’s much more difficult to get a number out of a DataSet than it is to get a number out of a Strongly Typed object.

int myFooId = ((int)myDataSet.Tables[0].Rows[1][0].ToString());

In comparison to: -

int myFooId = Foos[1].Id;

Knowledge of the Data Structure, developers need to know the structure/schema of the Data stored within DataSet’s to get the best out of them, and DataSet’s do not lend them selves to this aim, however when using Strongly Typed Objects your Data Structure is already mapped out in Properties and Methods on your objects.

As a Developer using a DataSet you need to know what the field names are called exactly or at which index in your DataRow’s the field you are looking for can be found: -

int myFooId = ((int)myDataSet.Tables[0].Rows[1][0].ToString());

int myFooId = ((int)myDataSet.Tables[0].Rows[1][“Id”].ToString());

The above is acceptable if there will only be one developer working with the code (a personal project for example), however in a team environment Developers find code that takes the responsibility away from them understanding and knowing the Data Schema much easier to work with.

Special Methods, cannot be added to your DataSet’s easily, however using Strongly Typed objects it is possible to have methods sitting inside your objects that can expose business logic, for example using the Strongly Typed Foo object we can perform actions that would with DataSet’s be a separate method call: -

Foos[1].SubmitToQA();

This kind of functionality is even more useful when thinking about Collections of objects, for example you may want to do some filtering on the Foos Collection, you may need to know what the Minimum and Maximum Price’s of the Objects in the Collection are, you’d just add two properties to the FooCollection class as so -

double MinimumPrice = Foos.MinimumPrice;

double MaximumPrice = Foos.MaximumPrice;

Strongly Typed Objects within Strongly Typed Objects, are very easy to create and use, and again they follow the Data Structure issues that have been mentioned above. Taking our Foo object again, we’ll look at a sample of this functionality.

int myDerivativeId = myFoo.Derivative.Id;

But even nicer than the above is the ability to have Collections within your objects, so you might have something like this: -

string myOptionName = myFoo.Options[0].Name;

Or Even: -

foreach(Option O in myFoo.Options)

{

          Response.Write(O.Name + “<br />”);

}

Data Binding, is just as easy with Strongly Typed Objects as it is with DataSet’s. And in some cases it’s much easier, for example the Fields you need are all available in strongly typed names, and when you’re working with VS.NET with inline Code there is no Intellisense to help you out, friendly names are much more helpful. The Code Behind methods of Data Binding work as normal: -

Foos.DataSource = myFoos; //myFoos is of type FooCollection

Foos.DataBind();

Your inline Data Binding code is also the same: -

<asp:Repeater ID="Foos" Runat="server">

<ItemTemplate>

<SPAN class="body">Title: <%# DataBinder.Eval(Container.DataItem,"Title")  %></SPAN><br />

<SPAN class="body">Mileage: <%# DataBinder.Eval(Container.DataItem,"Miles","{0:N0}")  %></SPAN<br />

<SPAN class="body">Price: <%# DataBinder.Eval(Container.DataItem,"Price","{0:C0}")  %></SPAN><br />

</ItemTemplate>

</asp:Repeater>

You can even access your Strongly Typed objects where normally you would have to use ItemArray’s: -

private void Foos_ItemDataBound(object sender, System.Web.UI.WebControls.RepeaterItemEventArgs e)

{

          BusinessObjects.Foo myFoo = new BusinessObjects.Foo();

          if (e.Item.ItemType == ListItemType.Item || e.Item.ItemType == ListItemType.AlternatingItem )

          {

                   myFoo = ( ( BusinessObjects.Foo ) e.Item.DataItem );

          }

          System.Web.UI.HtmlControls.HtmlGenericControl PriceChangeSection = ((System.Web.UI.HtmlControls.HtmlGenericControl )e.Item.FindControl("PriceDifferenceSpan"));

          if (PriceChangeSection != null)

          {

                   if (myFoo.OldPrice > 0)

                   {

                             PriceChangeSection.Visible = true;

                   }

                   else

                   {

                             PriceChangeSection.Visible = false;

                   }

          }

}

Unit Testing, is very simple using Strongly Typed Objects, you can create them in code, you don’t need a Database to be in place to retrieve Data from, and you can test your Business Logic in the same place as you’re testing your Data Structure.


View Entire Article

User Comments

Title: Mr.   
Name: Alan
Date: 2007-12-28 6:00:51 AM
Comment:
Another reason to use strongly typed objects over datasets is the size of a dataset... For instance if you are building a distributed app and want to send object over the wire to an app server then the overhead of using datasets is huge just because of their serialization size when comapred with strongly typed objects.

Travel boy this is why strongly typing datasets is not a great idea most of the type. You want to avoid the dependency on datasets too.
Title: what about dynamic connection ?   
Name: Sam
Date: 2006-07-19 5:55:06 PM
Comment:
Hi,
Nice article. But you don't go through connection strings. One problem I have is how to pass DYNAMICALLY a connection string to the dataAdapters at runtime. Say that I have a different connection string for each user, stored in a Session variable, how would I pass that to the xsd each time I want to use of a dataTable ?
Title: UML   
Name: Magnus Andersson
Date: 2005-06-10 4:18:14 AM
Comment:
WowWowWow !

Now i can design strongly typed object(dataset) in the whole project, without XML Schema.
This is great when i working with UML Design, because
ADO.NET object is a mess in UML design.
It is now time to build a automatic UML to dataset Class generator
Title: travelboy   
Name: travelboy
Date: 2005-06-08 12:15:54 PM
Comment:
Would advise looking into typed datasets as oppossed to spending hours defining your own collections.






Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2017 ASPAlliance.com  |  Page Processed at 2017-08-17 11:06:13 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search