Object-Oriented Programming Applied: A Custom Data Class
(Page 1 of 7 )
Have you ever been annoyed at the number of steps required to get data in and out of a database in .NET? Do you wish there was a simpler way? This article explains how to write the SQL statements once and manipulate the data with less code than the traditional method requires. It is excerpted from chapter five of the book
Maximizing ASP.NET: Real World, Object-Oriented Development, written by Jeffery Putz (Addison-Wesley Professional, 2005; ISBN: 0321294475).
In Chapter 1, “The Object Model,” I gave you an analogy that compares the concept of a class to that of a car. A class encapsulates some kind of functionality into one neat and simple package.
Many Web coders who have used other platforms such as PHP or Cold Fusion are a little surprised at the number of steps required to get data in and out of a database in .NET. Just to get a few values out of the database, you need to create a connection object, a command object, and then at the very least a DataReader. (In all fairness, you get back much of your time when data binding!) Sounds like the perfect place to build a useful class!
If we put all of our database logic into one class, we can write the SQL statements once and manipulate the data with far less code throughout our application. You’ll also benefit from having just one place to change code if you decide to use a different database (such as Oracle). Best of all, implementing a data-caching scheme is that much easier when all of your data code is in one place.
To help you see the benefit of this write-once, use-everywhere class, Listing 5.1 shows a code sample that creates a row in our database, reads the row, and then deletes it, all via a class that we’ll build in this chapter.
Listing 5.1 A class in action
C#
// Instantiate the Customer class using the default constructor Customer customer = new Customer();
// Assign some of its properties
customer.LastName = "Jones";
customer.FirstName = "Jeff";
// Call its Create() method to save the values in the database,
// and get its new primary key (CustomerID) value
int customerID = customer.Create();
// Instantiate the Customer class using the constructor that takes
// the CustomerID as a parameter
Customer customer2 = new Customer(customerID);
Trace.Write("LastName: " + customer2.LastName);
Trace.Write("FirstName: " + customer2.FirstName);
// Change the value of the ?rst name then save the changes
// to the database
customer2.FirstName = "Stephanie";
customer2.Update();
// On second thought, let's just delete the record entirely
customer2.Delete();
VB.NET
' Instantiate the Customer class using the default constructor
Dim customer As New Customer()
' Assign some of its properties
customer.LastName = "Jones"
customer.FirstName = "Jeff"
' Call its Create() method to save the values in the database,
' and get its new primary key (CustomerID) value
Dim customerID As Integer = customer.Create()
' Instantiate the Customer class using the constructor that takes
' the CustomerID as a parameter
Dim customer2 As New Customer(customerID)
Trace.Write(("LastName: " + customer2.LastName))
Trace.Write(("FirstName: " + customer2.FirstName))
' Change the value of the ?rst name then save the changes
' to the database
customer2.FirstName = "Stephanie"
customer2.Update()
' On second thought, let's just delete the record entirely customer2.Delete()
You can see by these few lines of code that we didn’t go through the entire process of creating connection, command, and other data objects. A few simple method calls are all we need to manipulate the data. Imagine how much time you’d save if you had to manipulate the data in dozens of places around your application!
This is a good place to mention that, in terms of n-tier architecture (see Chapter 4, “Application Architecture”), this sample class we’re about to build does not create the discrete layers often representative of such architectures. We’re going to combine data container classes and data access into one package. That isn’t wrong per se, and in fact it might be just what you need in your own application.
Next: Analyzing Design Requirements >>
More ASP.NET Articles
More By Addison-Wesley/Prentice Hall PTR
|
 This article is excerpted from chapter five of the book Maximizing ASP.NET: Real World, Object-Oriented Development, written by Jeffery Putz (Addison-Wesley Professional, 2005; ISBN: 0321294475). Check it out at your favorite bookstore. Buy this book now.
|
|
