Properties or parameters : what's best performing?

[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.

 

[Larry Serflaten]

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?

If you imagine your code is in California, and a needed object is in
New York, and the only way to send messages between the two is
to tie a note to a pigeon and send it on its way....

Are you going to send off a pigeon every time you need to access
a property, and then wait for a return pigeon before sending off another?
Or are you going to want to write all the information down
in a note and send off one pigeon to get that object to respond?

The point I am making is that it matters what kinds of boundries you
plan to cross. ASP sounds like you're using the internet, or at least
a network of some kind, certainly not a locally referenced object.

In that case, avoid chatty objects (Chatty = forcing required calls
for normal use; ex: setting properties), and go the parameterized route.

HTH
LFS

 

[Cor Ligthert]

Perre,

I am glad I don't know all those troubles you write, however maybe can I
tell you what for me a VBNet ASPNET application is to make it you more
clear. (I don't know if you ever tried the IIS project in VB6, than you have
already the idea)

When you use ASPNET in a scripting way you are in fact doing the same as
classic ASP.

However when you create it as an ASPNET project using VBNet than you create
a DLL.

That DLL is your middle tier. It is active as long as there are users active
and is an application shared by all active users (in fact a little bit
longer depending on the page sent back wait time).

Your webpages are the clientside, which interacts with that application.
That application gives information to the webpages, when they ask for that
by doing a post back, a page is than everytime created in the application
and is there as long as it is not again sand back to the client. In classic
ASP I called this my Com object that I had to register on the server.

ASPNET uses still sessions to hold the information, however as well you have
the viewstate (what does the information sent to the client and gets it back
with a postback) there is a cache which belongs to all clients and there are
shared classes which belong as well to all clients. For the last two you
have therefore to do all the same as in past when you hold information for
individual clients in that. You can as well use normal classes (objects).
The scope of those normal classes is as long as a page is on the serverside,
than all information will be destroyed from that.

If you use properties or parameters is not so important in this in my
opinion and only dealing about nanoseconds. That becomes in my opininion
important when you start serializing your dataobjects.

Maybe you know this above already, however I was not sure when I saw your
message.

Just my thoughts.

Cor

 

[Guest]

The point I am making is that it matters what kinds of boundries you
plan to cross. ASP sounds like you're using the internet, or at least
a network of some kind, certainly not a locally referenced object.
In that case, avoid chatty objects (Chatty = forcing required calls
for normal use; ex: setting properties), and go the parameterized route.

Thanks Larry,
I like the metaphorical way you explain, but English is difficult to me.
So, I'm afraid I might miss an important nuance here.

May I conclude :

1) use properties whenever the class/DLL will run on your local machine
2) use functions and parameters whenever the class/DLL is on another machine
(internet or LAN)

This makes me wonder ...

1) Why ever using properties? When using parameters you have classes that can
work well local and remote, so scalability is there when my project grows
from single user to n-tier multi-user ... or are there cases in which
properties (or class scope variables) have advantages above parameters?

I guess ...

2) sometimes you have no alternative and you have to store some data (public
or private) in an object
3) properties avoid you have to pass the same values multiple times as
parameters to functions ... when 1 function might be called multiple times
during the lifetime of the object ... or when multiple functions in the same
class need to use the same values? So we win by assigning only once?

Final questions
4) Is there an explicit set of rules to determine whether to use parameters
or properties, is there some documentation on the net (or in books) about
this issue?
5) Is com+ still around in vb.net? Can you write vb.net DLL's, drop them in
COM+ environment and have advantages by doing so? Can vb.NET EXE's call .NET
DLL's on other machines?

Thanks a lot.

 

[Cor Ligthert]

Larry,

I started with trying to use your classes in the cardgame, however I am
trying to translate them to C#.

Cor

 

[Guest]

I'm not a seasoned programmer but it seems to me that you will for the most
part have to store some information (properties) either inside the class or
outside. For example, if you have a value that changes everytime you call
the method, then it's probably better to use parameters. On the other hand,
if your value remains the same for various calls to the method, it would be
better to store the value inside the class via a property instead of outside
the class.

 

[Larry Serflaten]

Thanks Larry,
I like the metaphorical way you explain, but English is difficult to me.
So, I'm afraid I might miss an important nuance here.

You probably got all there was to get. You are asking about properties
or parameters, but in that question you include making calls out to some
other entity. I was addressing the call part, and not so much any differences
about using properties, or parameters.

As I indicated, there is need of consideration when you start
calling out to objects that are farther and farther away, (crossing more
boundries, as was mentioned).

Final questions
4) Is there an explicit set of rules to determine whether to use parameters
or properties, is there some documentation on the net (or in books) about
this issue?
5) Is com+ still around in vb.net? Can you write vb.net DLL's, drop them in
COM+ environment and have advantages by doing so? Can vb.NET EXE's call .NET
DLL's on other machines?

See if this paper can help give you some background information:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetremotearch.asp

Again, this is not so much about properties/parameters, but more about
interaction between objects that are physically separated.

HTH
LFS

 

[Larry Serflaten]

I started with trying to use your classes in the cardgame, however I am
trying to translate them to C#.

BAH! C#, How dare you!!!

IIRC, the cards (assemblies) were made CLR compliant, so they should
be able to be used form any .NET language.... Why translate them?

LFS

 

[Cor Ligthert]

IIRC, the cards (assemblies) were made CLR compliant, so they should
be able to be used form any .NET language.... Why translate them?

For the challenge



Cor

 

[Guest]

Cor, Dennis Larry,
Thanks for your lightening answers

My burden -sometimes a quality- is that each answer makes me start thinking
again ending up with more new questions

Since ASP.NET is new to me, I think I should read some more books
about this and learn by experiment, by writing classes with and without
parameters,
by logging the performance. I guess I'll have to conclude codedesign should
be
adapted to the nature of the class, depending on what they have to do and
depending on when, where and how many times they're used.

I'll end with a concrete situation and answer, so I can start
programming with peace of mind in 2005.

Best Wishes!!!

I've got an ASPX registration form in which users can fill in 10 properties
(name, address, phone, ...). There I have two ways to put the properties
into my database when the user clicks the "Register" button.

1)
'class with properties
objx = new classuser1
'move form/screen values to objectproperties
objx.name = control1.text
objx.address = control2.text
....
'call objects function assigning encapsulated properties to parameters of my
stored proc
Returnvalue = objx.insertuserdata()

2)
'class without properties
objz = new classuser2
'call objects function passing form/screen values as parameters
'which will be passed to parameters of my stored proc
Returnvalue = objz.insertuserdata(contol1.text, control2.text, ...)


Both work fine. Data is stored. Performance difference is neglectable ...
I'm satisfied ...

But than I realise ...
When the user logs in ...
believe it or not ...
On each page of my website I want to show all userdata ...

What should I do now?

Solution 1)

Use objx of classuser1 on the login form
Assign values to the properties of objx and then pass the object
around between all pages the user browses to.
....
and here I wonder whether

a) those properties stay in memory of the server which might
cause memory overload when 1000 users are logged in

or
b) those properties will be sent inside Html between client and server
all the time while surfing but without it's overloading the memory of
our server.

I guess I've to do some more research here about the differences
between viewstate, caching, sessionstate and normal classes to
realize what happens?


Solution 2)

I use objz of classuser2. I only pass the unique key of the user
between the pages and on each pageload I execute the function ...

mydatareader = objz.GetUserData(Userid)
call moveDataBaseDataToScreenControls(mydatareader)


What do you suggest to do in this concrete situation?

Thank you!!!
Perre.

 

[Cor Ligthert]

Piere

I guess I've to do some more research here about the differences
between viewstate, caching, sessionstate and normal classes to
realize what happens?

Yes and than read first that part I wrote about that again and than
especially that a normal class holds no information when a page is sent back
to the client. A shared class holds information between the posts, however
that will give you a lot of work indexing all information used by the client
(and clean up when he stops answering while you do not know that when he
does stop in the middle), while a session does that all automaticly for you.

You can as well think about creating your classes and than serialize them
inside a sessionitem and deserialize when there is a postback.

Just my thought,

Cor

 

[Stefan]

Hi Pierre,


I just wanted to point out that although writing out properties can be a
pain it is considered best practice. Also if you have to do a lot of
validation on your data you don't have it splashed around everywhere it
is all contained in the property. Properties = better versioning
capabilities and scalability.

My suggestion would be to use properties with overloaded constructors
which allows you to construct a valid object in one call.

If you go the parameter route you won't be able to use a lot of the
frameworks Reflection Capabilities because you will have very little
self contained meta-data in your objects.

If you are interested I could post a class for you to look at.


Happy Coding,

Stefan
C# GURU
www.DotNETovation.com

"You always have to look beyond the horizon and can never be complacent
-- God forbid we become complacent."

Jozef Straus

 

[Guest]

Hi Stefan,

I'd really appreciate a post of a class.
Mostly learn more from pieces of code from collegues than from books.
Might also get me an idea of the concept "overloaded constructor".

Thanks.
(e-mail address removed)