BorlandTalk.com

Colin Basterfield · Guest

Hi all,

Not sure if this is the most appropriate place for this so apologies if
inappropriate...

I have come back to a framework I built some time ago to see where some
refactoring can take place to improve performance, and following some test
have highlighted a few areas where some changes would definitely benefit the
application.

I have however come to a point where there are two ways to make the change
and I wanted some objective input to help me decide what is the better way.

My app is split into the classic three tiers, Backend, Business and
Frontend. Using the template pattern, abstract methods are called from base
classes which build a list of business objects from the database given a
search criteria. Each business object has its own set of fields all of
varying types, i.e. String, Float, Integer, DateTime.

The original setup called an abstract method in the chosen backend object,
say for this example we have an Activity business object, so a corresponding
backend object exists as does a Config Activity front end object.

Assuming a wild card search criteria an activity list could be generated, so
as each 'row' was read from the database it created a new Activity business
object, and called a method on the Activity backend object to transfer the
data to each field in the Activity business object. This proved time
consuming performance wise as some of the objects had many fields, so took a
while to be populated.

I changed this a while back so that in the base business object class there
was a string list which held the data for each field and had an enumerated
type which facililated access to the data for viewing purposes on a grid for
selection, and then when the User chose an actual Activity from the result
set list then there was no real need to have the field values in their
native type.

I have now realised that in certain areas where lists of business objects in
their native type are being generated the performance is appalling, so
looking back into the framework I see that the same problem is present, i.e.
the time to populate native type fields is time consuming and similarly the
only real time that one needs the data in native type is at the point of
Edit/Config.

So I figured that I would keep the native type fields for each business
object, and then have an abstract method that would 'PopulateObjectToType'
when the User chose to edit this field. But then I thought well shouldn't
it really be properties that simply provide the native type field when
required, so now my dilemma is which to go for, the overall Population at an
appropriate time OR simply pull the values to a native type when required.
But THEN I thought well what is the point of having the native type fields
in the business objects at all, why not just have them held in a list of
strings and read from and write to them which makes it all sound far simpler
to maintain, as in the original two options I see there being a potential
for duplication of data, and hence potential for data loss.

So what do people think about this, assuming they haven't lost the will to
live at this point?

Many thanks for any input on this...
Colin B