Communication with components

[calahans]

Hi,<br>
<br>
I'm still at the experimental phase with DCOM. I'm looking for the most efficient way to pass recordsets between layers. For example, say I have a listview in the UI which I want to populate from my db. <br>
<br>
Do I create a recordset in the UI component and pass it in, by ref, as a paramater to the getrecs() method of data component. Or do I create a recordset object in the UI and set it equal to my datacomponent.getrecs().<br>
<br>
I heard that passing by val is very expensive on a network. Do I use disconnected recordsets and pass them about?<br>
<br>
Is the previous passage even coherent?<br>
<br>
C

 

[johnk]

Hi Calahans,<br>
<br>
This is from a manager - beware the details.<br>
<br>
The way we do it is to write a method in the DataAccess tier that returns a variant value. <br>
The method sets itself = to recordset.GetRows(recordset.recordcount)<br>
<br>
This returns a variant containing an array that houses all of the data from that recordset.<br>
<br>
JohnK

 

[calahans]

Thanks John,<br>
<br>
I had heard of using a variant to pass the information back. I suppose this takes away all the network traffic that passing recordsets causes.<br>
<br>
I'm slightly reluctant to use arrays to hold recordsets, but if that is how its working for yourself then I'll give it a go.<br>
<br>
Cal

 

[StevenTaylor]

Calahans,<br>
<br>
Currently, we are building objects that contain all the information for a single DB record, then making a collection object that loads and contains all of these objects. I don't know if that makes any sense, but that works really well for us.<br>
<br>
T

 

[calahans]

Hi Steven,<br>
<br>
You create an object which holds details of a single db record - are these remote objects, or local. If they are remote how are you returning this information to the the UI layer (say to populate a list view control on the UI)?<br>
<br>
Thanks,<br>
<br>
C

 

[StevenTaylor]

C,<br>
<br>
These objects are in the business objects tier and are located on the client machine. They populate themselves by creating temporary objects in the data services tier, calling the load functions of these objects, and removing these objects. This is how we handle all of the persistence (loading, saving, and deleting). These business objects on the client machine do not contain any SQL or any knowledge of the database. Hope that helps a bit.<br>
<br>
Steve<br>

 

[JStandley]

Look into XML support in your environment. I'm in J++ thin-client world, not sure about VB. XML is a good universal language for any component to format its return data to client layers. It's a single string, easy to marshal between languages, platforms, etc. The downside is the coding effort and runtime overhead of generating and parsing XML.<br>
<br>
We put hand-generated code in the data objects to abstract the database. For example, we hide the details of table structures, complex joins, multiple queries, etc. We return meaningful business names for fields instead of the cryptic abbreviations mandated by the data admin on the database. <br>
<br>
The architectural objective is to hide all knowledge of the database from users of the component, so the data component author can be free to change the database without telling his clients. With that priority, passing around a recordset would be barely better than putting SQL in the GUI.

 

[VB400]

Calahans,<br>
<br>
Did you get the answer you needed? If not, please post a note and maybe I can be of help!