Using Strongly Typed Objects and Collections to replace DataSet’s in your .NET applications.
page 3 of 4
by Phil Winstanley
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 26382/ 82

Populating objects and collection from Databases

The function of populating your objects is relatively simple, all you basically need to do is retrieve the Data from it’s store and pass it in to your objects.

The best way of achieving this is by having all of your Data Access code in one place, then using that code throughout your applications. The Data access code can be project specific or more general and this will depend on your needs.

An example of this follows: -


public FooCollection PoshFoos()


          //Setup some Variables

          string ConnectionString = ("MySqlServer");

          string StoredProcedure = ("MyStoredProc");

          FooCollection CC = new FooCollection();

          //Set up the Parameters for the Database Code

          NameValueCollection Params = new NameValueCollection();


          //Retreive the Data using our custom call (DAL)

          DataSet Foos = DataAccess.Out.GetDataSet(ConnectionString,StoredProcedure,Params);

          //Loop through the rows collected and populate the Foo Object

          foreach(DataRow DR in Foos.Tables[0].Rows)


                   Foo C = new Foo();


                   C.Id = Convert.ToInt32(DR["FooId"].ToString());

                   C.Title = DR["Title"].ToString();

                   C.ExteriorColor = DR["ExteriorColour"].ToString();

                   C.InteriorColor = DR["InteriorColour"].ToString();

                   C.InteriorMaterial = DR["InteriorMaterial"].ToString();

                   C.Price = Convert.ToDouble(DR["Price"].ToString());

                   C.Miles = Convert.ToInt32(DR["Miles"].ToString());

                   C.Registration =  DR["Registration"].ToString();

                   C.Transmission = new Transmission(DR["TransmissionCode"].ToString(),DR["TransmissionName"].ToString());

                   C.Fuel = new Fuel(DR["FuelCode"].ToString(),DR["FuelName"].ToString());

                   C.Manufacturer = new Manufacturer(Convert.ToInt32(DR["ManufacturerId"].ToString()),DR["ManufacturerName"].ToString());

                   C.Model = new Model(Convert.ToInt32(DR["ModelId"].ToString()),DR["ModelName"].ToString());

                   C.Derivative = new Derivative(Convert.ToInt32(DR["DerivativeId"].ToString()),DR["DerivativeName"].ToString());

                   C.Description = DR["Description"].ToString();

                   C.HoldingCenter = new Center(Convert.ToInt32(DR["CenterId"].ToString()),DR["CenterName"].ToString());



          //Return the Foo object

          return CC;



Sometimes you will even want to encapsulate the above and add application logic such as Caching, and example of which follows: -


public BusinessObjects.FooCollection All()


          FooCollection CC = new FooCollection();


          if (System.Web.HttpContext.Current.Cache["PoshFoos_" + _Results.ToString()] != null)


                   CC = ((FooCollection)System.Web.HttpContext.Current.Cache["PoshFoos_" + _Results.ToString()]);




                   ReturnFoos RC = new ReturnFoos();

                   RC.NumberOfRowsToReturn = _Results;

                   CC = RC.PoshFoos();

System.Web.HttpContext.Current.Cache.Add("PoshFoos_" + _Results.ToString(),








          return CC;



Another way, sometimes the best for persuading others to adopt this technique is by having methods on your objects that perform the data access, an example of which follows.





Whilst this moves away from a disconnected architecture it allows developers to get away without having to perform any manual Data Access.

It’s best to place all Data Access code that is used inside your objects in a separate Data Access class of some sort, this way you do not have to clutter your objects with a lot of methods to retrieve data, but instead instantiate your Data Access class, give it the Object you want Filling, and pass it the Criteria against which you wish the SQL Queries to be run. This is Similar to the way DataAdapter’s are currently used. 

There is no “right” was to populate your objects, all have their pitfalls.

View Entire Article

User Comments

Title: Mr.   
Name: Alan
Date: 2007-12-28 6:00:51 AM
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
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
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
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-2020  |  Page Processed at 2020-07-05 3:54:04 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search