Properties and Object Oriented Database Development with VB.NET 2005
(Page 1 of 4 )
This is the third article in a series on developing object oriented database applications using Visual Basic.NET 2005. In this article, I shall deal with the concept of “properties” in depth, along with data access.
A downloadable file for this article is available
here.
For this article, I assume that you know enough about the basics of working with VB.NET controls, ADO.NET, and so forth of using Visual Basic.NET 2005. Even though this article only gives you the basics of OOP along with database development, I shall extend it in the form of a series to cover the most advanced topics in Visual Basic.NET 2005. If you are very new to OOP in VB.NET, I suggest you go through my first article in this series.
The entire source code for this article is available in the form of a downloadable zip. The solution was developed using Microsoft Visual Studio 2005 Professional Edition with Microsoft SQL Server 2005 Developer Edition on Microsoft Windows Server 2003 Enterprise Edition. Even though I believe that the source code available with this contribution can work with Microsoft Visual Studio.NET 2003/2002, I didn’t really test it in any other environment. I request that you post in the discussion area if you have any problems with execution.
To make this article simple, I created a sample database named “sample,” with a table “emp” containing the columns empno (string), ename (string), sal (double) and deptno (integer) and a few rows.
Defining your own properties within a class: the basics
In my first article, I covered the concept of fields (or member variables). Fields are mainly used to contain data. Sometimes, the data in fields may be sensitive to the logic, where they must not be altered by the calling program. Further, to assign data to the fields, we may need to enforce some validation.
To put it simply, we need to protect the integrity of the data available in the fields along with proper accessibility. To solve all those needs, VB includes a separate construct called “Property.” Let me rewrite a single field with proper accessibility and validation as follows:
Public Class Emp
...
Private m_sal As Double
Public Property sal() As Double
Get
Return m_sal
End Get
Set(ByVal value As Double)
If value < 0 Then
Throw New Exception("Salary cannot be negative")
End If
m_sal = value
End Set
End Property
...
End Class
The first and the most important statement is the following:
Private m_sal As Double
You can observe that I replaced the previous “public” with “private.” This causes the field “m_sal” to be “private” to the class; it is accessible only within the class and not outside the class. By making it private, we protect it totally by hiding it from any other source, apart from the class where it has been defined.
If the fields are made “private,” we need to provide some type of bridge to access them in a secured manner (which may also include some validation). That bridge will be nothing but the “Property” construct. A “Property” construct bridges the gap between the private fields and the calling program. The calling program accesses the contents of the private field with the help of the “Property.” The “Property” makes sure that it is secured with valid data.
The “Property” construct mainly contains two parts, “get” and “set.” The part “get” is executed when we try to retrieve from the “Property.” The part “set” is executed when we try to assign to the “Property.” A simple example of the get/set access of property is as follows:
Me.txtEmpno.Text = "1001"
Dim empno As String = Me.txtEmpno.Text
Within the above statement, I am assigning some value to the property “text,” which causes the part “set” to invoke (by passing “1001” as parameter to the part “set”). The second statement simply retrieves some value from the property “text,” which causes the part “get” to invoke.
Next: The class “Emp” rewritten with properties >>
More Visual Basic.NET Articles
More By Jagadish Chaterjee
