pass datatable in event or grab from property or pass in function?

[Raymond Lewallen]

Which would be the proper way or the reason for using any of the following
or combinations of the following? These are the 3 ways I've figured I can
do what I want to do, I just don't know which would be best:

#1
' Everything is create upon instantiation. Once completed, datatable can be
obtained from the property.
Public Class A

Private dt as DataTable

Public Sub New()
Load()
End Sub

Private Sub Load()
' Do stuff to create a datatable
dt = MyCreatedDataTable
End Sub

Public ReadOnly Property YourDataTable() As DataTable
Get
Return dt
End Get
End Property

End Class
'**********************************************************************
#2
' Everything created upon instantiation. DataTable is passed in the
Complete event.
Public Class A

Private dt as DataTable
Public Event Complete(ByVal dt As DataTable)

Public Sub New()
Load()
End Sub

Private Sub Load()
' Do stuff to create a datatable
dt = MyCreatedDataTable
RaiseEvent Complete(dt)
End Sub

End Class
'**********************************************************************
#3
' Nothing created upon instantiation. Expose Load as a function to return a
datatable.
Public Class A

Private dt as DataTable

Public Sub New()
' Do nothing
End Sub

Public Function Load() As DataTable
' Do stuff to create a datatable
Return MyCreatedDataTable
End Sub

End Class


Thanks for you input,

Raymond Lewallen

 

[Raymond Lewallen]

Sorry, in #3 disregard that Private dt As DataTable. That should not be
there.

 

[Jay B. Harlow [MVP - Outlook]]

Raymond,
What specifically is it that you want to do?

As each method is useful in its own regard, with out really knowing
specifically what you are attempting to do, its hard to say which of the
three are better, or even if #4 or #5 would be better...

Hope this helps
Jay

 

[Marina]

I think that all really depends on what your requirements are.

For example, is 'A' valid without having a valid datatable internally? If
it is not valid, then #3 is out, because it relies on the developer to call
Load manually - and only then making that instance of A valid. The object
should be valid and ready to be used after the constructor fires. Though you
are not storing a reference to the datatable in the object, so perhaps it is
not an issue.

Another example, if the developer might need to grab the datatable at
various times (not just once after the construction of the object), then #2
is out, since the Complete event fires just then. A bigger problem is, I
dont' see how you can attach an event handler, to an object that doesn't
exist. You can only do it after the constructor finishes - but at this point
the Complete has fired already, and it is too late.

I would say #1 is pretty typical when the DataTable is part of the object
and needs to be instantiated as part of the construction of A. That way you
ensure that it gets created, and give the developer a way to access it if
need be.

 

[Raymond Lewallen]

What specifically is it that you want to do?

Do to the nature of the program and my employer, I cannot attach source
code. However, I can tell you the datatable is being used to populate a PDF
form.

Let me ask you this: take the following 2 examples #10.1 and #10.2, given
the code already posted #1 where the property is used to get the datatable.
Would you go ahead and cache the datatable locally or continue to use the
property? Consider the datatable is ALWAYS a single row, with anywhere from
25 to 200 columns, depending on the report we are populating. In previous
post example #3, Load() must be called manually to get a datatable, and this
will always need to be called, validating the need of instantiating A, so we
will always get a datatable returned and cached locally. Would this be
preferable to using the property, if you are going to choose #10.1 below as
the more appropriate approach? FYI, currently the implementation is #1 from
the previous code and #10.1 below, but compiles larger with more IL code.
#3 with #10.1 compiles with the least amount of IL code. To me, readability
is the same regardless of which combinations.

#10.1
Class B

Public Sub MakeForm()
Dim myA As New A
Dim dt As DataTable = A.YourDataTable
' use dt to do various things, repeatedly using dt. One example is
this loop.
For Each column As DataColumn in dt.Columns
' Do something
Next
End Sub

End Class
'*********************************************

OR

#10.2
Class B

Public Sub MakeForm()
Dim myA As New A
' use A.YourDataTable to do various things, repeatedly using
A.YourDataTable. One example is this loop.
For Each column As DataColumn in A.YourDataTable.Columns
' Do something
Next
End Sub

End Class
'*********************************************

 

[Raymond Lewallen]

I think that all really depends on what your requirements are.

Please read my response to Jay B. Harlow. Your input and following of this
post is greatly appreciated. This may help clarify your first 2 paragraphs
of your initial response.

For example, is 'A' valid without having a valid datatable internally?

No, it is not.

Though you are not storing a reference to the datatable in the object, so perhaps it is
not an issue.

This is what I was thinking, but wasn't sure.

Another example, if the developer might need to grab the datatable at
various times (not just once after the construction of the object), then #2
is out, since the Complete event fires just then. A bigger problem is, I
dont' see how you can attach an event handler, to an object that doesn't
exist. You can only do it after the constructor finishes - but at this point
the Complete has fired already, and it is too late.

Actually, the event does fire and all works great when the calling class
does:

Dim myA As A
AddHandler myA.Complete, AddressOf UseMyDataTable
myA = New A

Sub UseMyDataTable(ByVal dt As DataTable)
' This does get executed.
End Sub

UseMyDataTable is being executed with the complete event firing.

I would say #1 is pretty typical when the DataTable is part of the object
and needs to be instantiated as part of the construction of A. That way you
ensure that it gets created, and give the developer a way to access it if
need be.

#1 is the current implementation. The developer will always have a need to
access the datatable.

Again, please read my post to Jay, as it is directed to the both of you.

Thanks,

Raymond Lewallen
Federal Aviation Administration

 

[Raymond Lewallen]

After further examination of the IL, it doesn't appear to matter whether you
cache the datatable locally or use the property, in this instance, because
either way it is storing the datatable to a System.Collections.IEnumerator
on the stack and using that, never returning back to the code for the
initial datatable. Perhaps just calling the property would be better,
eliminating the extra local on the stack created to store the datatable
locally.

 

[Jay B. Harlow [MVP - Outlook]]

Raymond,
I normally write "correct" code first, by "correct" I mean follow the Object
Thinking (Object Oriented) paradigm. Only after a routine has proven to have
a performance problem via Profiling will I worry about optimizing that
routine.

Remember the 80/20 rule: 80% of the time of your code falls within 20% of
your code.

It doesn't really make sense to optimize the 80% of your code where only 20%
of the time is spent, does it?

For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware/yetOptimization.pdf

For a list of Martin's articles see:

http://martinfowler.com/articles.html

Info on the CLR Profiler:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenethowto13.asp

http://msdn.microsoft.com/library/d...y/en-us/dndotnet/html/highperfmanagedapps.asp

Hope this helps
Jay