You open the connection, create the reader, then close the connection.
As the reader needs the connection to be open, it unusable after the
connection has been closed. When the method returns the reader, it's no
longer possible to read anything from it.
It's just an example to show that the reference can be a reference to an
interface instead of a reference to the class. It's of course only
useful when one method creates the object and another method uses the
object (in the shape of the interface).
A regular class just have some behaviour, it doesn't define behaviour
for other classes.
An abstract class on the other hand, can both define behaviour for
derived classes, and implement behaviour itself. An abstract class that
doesn't implement anything itself is similar to an interface.
Yes, you can make a class that compares two values, but you can't make
the Array.Sort aware of the fact that the class can do this if you don't
use the interface.
Right. I missed to remove the access modifier in the interface. You
can't specify any access level in an interface as everything is always
public.
You have to put them on separate lines:
Public Class DBSettings
Implements IDBSettings
You also have to specify Implements on the method:
Public Function QueryDB(ByVal qry As String) As SqlDataReader Implements
IDBSettings.QueryDB
(I usually do this in C#, that isn't line based, and that just
identifies the methods for the implementation by name.)
Goran, I am highly obliged to you for putting in so much effort & time
in trying to make me understand interfaces. I really appreciate it
from the bottom of my heart (& I really mean it). Now I am getting a
hang of interfaces & their uses. I guess you must be pleased to know
that your efforts aren't being wasted!
Finally I could make that code work. This is the class (.vb) code (I
am reproducing the entire code so that someone else can benefit from
it in the future; after all everyone won't be as fortunate as me to
have a helpful guide like you):
Imports System
Imports System.Data
Imports System.Data.SqlClient
Public Interface IDBSettings
Property ConnectionString() As String
Function QueryDB(ByVal qry As String) As SqlDataReader
End Interface
Public Class DBSettings
Implements IDBSettings
Public ConnString As String
Private sqlCmd As SqlCommand
Private sqlConn As SqlConnection
Public Property ConnectionString() As String Implements
IDBSettings.ConnectionString
Get
ConnectionString = ConnString
End Get
Set(ByVal value As String)
ConnString = value
End Set
End Property
Public Function QueryDB(ByVal qry As String) As SqlDataReader
Implements IDBSettings.QueryDB
sqlConn = New SqlConnection(ConnectionString)
sqlCmd = New SqlCommand(qry, sqlConn)
sqlConn.Open()
Return sqlCmd.ExecuteReader
sqlConn.Close()
End Function
End Class
& this is the ASPX code:
<%@ Page Language="VB" Explicit="True" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>
<script runat="server">
Sub Page_Load(ByVal obj As Object, ByVal ea As EventArgs)
Dim boDBSettings As IDBSettings
Dim sqlDReader As SqlDataReader
boDBSettings = New DBSettings
boDBSettings.ConnectionString = ".........."
sqlDReader = boDBSettings.QueryDB("SELECT * FROM Table1")
If Not (sqlDReader Is Nothing) Then
dg1.DataSource = sqlDReader
dg1.DataBind()
sqlDReader.Close()
End If
End Sub
</script>
<form runat="server">
<asp
ataGrid ID="dg1" runat="server"/>
</form>
There is one thing I noticed when I made the reference to the
IDBSettings interface (instead of the DBSettings class) in the ASPX
code. I use Visual Web Developer 2005 for ASP.NET apps. When I typed
boDBSettings.
(notice the dot after boDBSettings), then VWD's intellisense lists
only 2 items - the property named ConnectionString & the function
named QueryDB but if I make the reference to the DBSettings class,
then apart from ConnectionString & QueryDB, VWD's intellisense also
lists other items like ConnString, Equals, GetHashCode, GetType,
ReferenceEquals, ToString etc.
So isn't this a disadvantage of using user-defined interfaces? Because
making a reference to the interface IDBSettings from the ASPX page
means I won't be able to use the built-in functions like Equals,
GetHashCode, GetType etc. (which would be available if I make the
reference to the DBSettings class instead). If I want to do the same
task which the function, say, Equals does, then I have to add more
code within the interface & the class (in the class file) which in
turn means more work for the programmer. So is using user-defined
interfaces worthwhile?
It's of course only
useful when one method creates the object and another method uses the
object (in the shape of the interface)
Sorry, Goran, I couldn't exactly understand the above statement. Could
you please elaborate on it a little bit (maybe with an example as I
find it easier to understand things with examples instead of just a
textual explanation)?
Thanks once again for your co-operation.
Regards.