P
Perre Van Wilrijk
Hi there,
When I started using VB6, I used to write classes with properties and
functions as following ...
Private lngf1 As Long
Private strf2 As String
Public Property Get f1() As Long
f1 = lngf1
End Property
Public Property Let f1(ByVal vnewvalue As Long)
lngf1 = vnewvalue
End Property
....
Public Function DLInsertData(ConnStr As String, Provider As String)) as Long
On Error GoTo Errorhandler
Dim cnDB As ADODB.Connection
Dim cmQ1 As ADODB.Command
Set cnDB = New ADODB.Connection
cnDB.Provider = parProvider
cnDB.ConnectionString = parConnStr
cnDB.ConnectionTimeout = 10
cnDB.Open
Set cmQ1 = New ADODB.Command
Set cmQ1.ActiveConnection = cnDB
cmQ1.CommandType = adCmdStoredProc
cmQ1.CommandText = "xx"
cmQ1.Parameters.Refresh
cmQ1.Parameters(1).Value = f1
cmQ1.Parameters(2).Value = f2
... etc
cmQ1.Execute
DLInsertadvstabl = cmQ1.Parameters(45).Value
cnDB.Close
Set cnDB = Nothing
Exit Function
Errorhandler:
Err.Raise Err.Number, Err.Source, Err.Description
End Function
So I populated the properties outside the class itself, mostly by assigning
form control values to the properties, followed by calling the function to
insert data into the database.
Later on I learned to avoid property declaration in VB6 Classes. I was told
to use parameters. So I had classes without properties, classes with
functions with lot of parameters like this one ...
Public Function DLInsertData(ConnStr As String, Provider As String, field1
As Long, field2 as string, etc) as Long
On Error GoTo Errorhandler
Dim cnDB As ADODB.Connection
Dim cmQ1 As ADODB.Command
Set cnDB = New ADODB.Connection
cnDB.Provider = parProvider
cnDB.ConnectionString = parConnStr
cnDB.ConnectionTimeout = 10
cnDB.Open
Set cmQ1 = New ADODB.Command
Set cmQ1.ActiveConnection = cnDB
cmQ1.CommandType = adCmdStoredProc
cmQ1.CommandText = "xx"
cmQ1.Parameters.Refresh
cmQ1.Parameters(1).Value = field1
cmQ1.Parameters(2).Value = field2
... etc
cmQ1.Execute
DLInsertadvstabl = cmQ1.Parameters(45).Value
cnDB.Close
Set cnDB = Nothing
Exit Function
Errorhandler:
Err.Raise Err.Number, Err.Source, Err.Description
End Function
As far as I remember this should be much beter once the DLL's had to be
placed in n-tier environments using MTS or COM+. I believe the system has
to reserve space for the properties of all the objects instanceiated by the
multiple users and that might eat memory and conflict with COM+ principles.
Nobody has ever confirmed me this theory and I didn't really need to know
all the answers at that time.
But now I'm starting to use ASP.NET and I have to write VB.NET code for
larger applications, I want to make the best code I can. So now I wonder
whether the theory above is true and whether it's also something to remind
in dot net.
So, is COM+ still an issue in dot net?
So, may I use property based objects in ASP.NET?
Or should I avoid properties in .vb classes and use functions with
parameters in order to obtain the best performance?
Thanks a lot.
When I started using VB6, I used to write classes with properties and
functions as following ...
Private lngf1 As Long
Private strf2 As String
Public Property Get f1() As Long
f1 = lngf1
End Property
Public Property Let f1(ByVal vnewvalue As Long)
lngf1 = vnewvalue
End Property
....
Public Function DLInsertData(ConnStr As String, Provider As String)) as Long
On Error GoTo Errorhandler
Dim cnDB As ADODB.Connection
Dim cmQ1 As ADODB.Command
Set cnDB = New ADODB.Connection
cnDB.Provider = parProvider
cnDB.ConnectionString = parConnStr
cnDB.ConnectionTimeout = 10
cnDB.Open
Set cmQ1 = New ADODB.Command
Set cmQ1.ActiveConnection = cnDB
cmQ1.CommandType = adCmdStoredProc
cmQ1.CommandText = "xx"
cmQ1.Parameters.Refresh
cmQ1.Parameters(1).Value = f1
cmQ1.Parameters(2).Value = f2
... etc
cmQ1.Execute
DLInsertadvstabl = cmQ1.Parameters(45).Value
cnDB.Close
Set cnDB = Nothing
Exit Function
Errorhandler:
Err.Raise Err.Number, Err.Source, Err.Description
End Function
So I populated the properties outside the class itself, mostly by assigning
form control values to the properties, followed by calling the function to
insert data into the database.
Later on I learned to avoid property declaration in VB6 Classes. I was told
to use parameters. So I had classes without properties, classes with
functions with lot of parameters like this one ...
Public Function DLInsertData(ConnStr As String, Provider As String, field1
As Long, field2 as string, etc) as Long
On Error GoTo Errorhandler
Dim cnDB As ADODB.Connection
Dim cmQ1 As ADODB.Command
Set cnDB = New ADODB.Connection
cnDB.Provider = parProvider
cnDB.ConnectionString = parConnStr
cnDB.ConnectionTimeout = 10
cnDB.Open
Set cmQ1 = New ADODB.Command
Set cmQ1.ActiveConnection = cnDB
cmQ1.CommandType = adCmdStoredProc
cmQ1.CommandText = "xx"
cmQ1.Parameters.Refresh
cmQ1.Parameters(1).Value = field1
cmQ1.Parameters(2).Value = field2
... etc
cmQ1.Execute
DLInsertadvstabl = cmQ1.Parameters(45).Value
cnDB.Close
Set cnDB = Nothing
Exit Function
Errorhandler:
Err.Raise Err.Number, Err.Source, Err.Description
End Function
As far as I remember this should be much beter once the DLL's had to be
placed in n-tier environments using MTS or COM+. I believe the system has
to reserve space for the properties of all the objects instanceiated by the
multiple users and that might eat memory and conflict with COM+ principles.
Nobody has ever confirmed me this theory and I didn't really need to know
all the answers at that time.
But now I'm starting to use ASP.NET and I have to write VB.NET code for
larger applications, I want to make the best code I can. So now I wonder
whether the theory above is true and whether it's also something to remind
in dot net.
So, is COM+ still an issue in dot net?
So, may I use property based objects in ASP.NET?
Or should I avoid properties in .vb classes and use functions with
parameters in order to obtain the best performance?
Thanks a lot.