I already have a class with several methods, one of which, given a Customer number, returns a Customer Value Object (properties-only) which itself has a collection of order objects.
Now, I need to be able to bind a progress query to a .net grid, so I want to pass a dataset handle, containing the customer and order temp-tables.
Should this new class/method
A) call the original class, then convert the customer object and order objects into temp-table records
B) read the database directly and construct the temp-table records directly from the table
Thanks
I already have a class with several methods, one of which, given a Customer number, returns a Customer Value Object (properties-only) which itself has a collection of order objects.
Now, I need to be able to bind a progress query to a .net grid, so I want to pass a dataset handle, containing the customer and order temp-tables.
Should this new class/method
A) call the original class, then convert the customer object and order objects into temp-table records
B) read the database directly and construct the temp-table records directly from the table
My answer is C. I wouldn't have put the data I into an object in the first place (and I know I'll get punished for that - when/if the ABL progresses further I'll revise the opinion). The object containing the data can't make it from the AppServer to the UI and the UI needs it in a table (of which kind ever). Two practical arguments for having the data in temp-tables or ProDatasets from the beginning.
But when one has converted the data into properties of an object, I'd rather go for option A. The data might have been abstracted from the DB (calculated fields etc.). The UI should leverage that by sourcing it's view to the object, not the DB. But it's certainly causing overhead. It's X times worse than not passing temp-tables BY-REFERENCE.
Is your architecture client server or AppServer?
I meant to say that option "B" does take the db table(s) and outputs
into a prodataset and returned by-reference.
Architecture is client/server only. Oh, and webspeed .
All inter-process comms is handled by messaging (Hi Greg!)
And you are right - being able to serialise an object is something
that is desperately needed. Having said that, I use a program to build
the value-objects source code, so adding the ability to serialise /
de-serialise as methods in the main class is trivial.
Julian
And you are right - being able to serialise an object is something
that is desperately needed. Having said that, I use a program to build
the value-objects source code, so adding the ability to serialise /
de-serialise as methods in the main class is trivial.
Certainly trivial to implement. But what's the cost a runtime? Compared to have the data in a prodataset from the beginning and pass the dataset?
Even if you are client/server, it is a good thing to think in terms of layer separation ... it will pay dividends in maintenance down the line. What it seems you have here is a data layer object which is currently producing a message data packet in the form of a value object. I think that is a good thing in terms of passing data to and from the business logic layer since it is highly decoupled and allows you to have the factory which createst the objects to be used in the BL. But, the new problem you are posing to us is really just passing some data right through the BL straight to the UI without computation or action. In that case, I would create a "set" object containing a TT or PDS and pass through the data in the form needed by the UI. I would even do this in an N-tier environment since you aren't going to use the data in any way in the BL.
For several dozen objects, hardly an impact.
I have a method that creates a dynamic temp-table, adds all the fields
of the object, creates a record, moves the properties of the object
into the appropriate field, convert the temp-table into xml and
deletes the temp-table and returns the xml as longchar data.
For a largish object (40+ properties), this takes 1164 ms for 1000
objects. Not so bad. Sure, not so fast as having a prodataset already,
but not so bad.
Julian