This thread http://www.psdn.com/library/thread.jspa?threadID=4653 is about wrapping a temp-table or not:
Thomas Mercer-Hursh:
"...
But your examples don't encapsulate the data ... they require the data structure to be identically defined in two different places at a minimum. Wrap that PDS in an object and pass the object and that characteristic disappears. You still would have the data and logic in different objects, but that is a different argument and one with some more complex issues.
..."
Mike Omerod:
"...
So at the risk of sounding obtuse, why don't you provide the community with an example of what your proposing? I for one would be curious to see this as an actual example.
..."
So basically you're talking about a code construct like this:
Interesting areas to discuss are;
a) Is this class now representing a resultset or a domain entity. The class incorporates currency, the current buffer, because it wraps a temp-table. That makes it non-reentrant, so the class can't be static (assume you need customer X and Y at the same time while validating something and you only have the static instance CustomerSomething).
When the class mimics a resultset, than you probably won't implement real business logic in that type of class, since it's not the responsibility of a resultset. Either way the class can do lazy loading, like fetching an address on demand. But a full blown domain entity would do more (prevent invalid customers to be stored and keep things consistent).
b) for 2) you want better support from the ABL so you can bind a property directly to a buffer field. This makes it possible to easily guard the setting of a buffer field with validation logic. A design question is wether or not you want validation logic at that place or not...
c) you probably don't need a DATASOURCE-object in this environment. The DA-class will do the required transformations.
d) for 3) and 5) you have the design question "what will the DA-class communicate with this class". Sure, the DA can implement the same pattern as this "CustomerSomthing" class, but this time directly bound to a database buffer.
e) for 3) you can move this kind of logic out of the class and move it to Thomas' dedicated Finder-class. But that approach will increase the likelyhood of an environment where CustomerSomthing classes are wrapping a single customer buffer. This will have at least two downsides:
e1) you will have to manage several CustomerSomething instances (since you have to make sure that you delete the class instances the Finder creates)
e2) creating a temp-table+buffer instance for every single record will kill the application (temp-tables are not designed to be used like this)
Theo wrote:
e2) creating a temp-table+buffer instance for every
single record will kill the application (temp-tables
are not designed to be used like this)
Thomas and I had a very long discussion (argument) about this, over a year ago. I argued that it should be reasonable to have one temp-table (passed by reference) which represents a query result set. You would only need as many objects (each with one buffer) as needed for the application - usually only one or two.
In other words: One temp-table per query result. One buffer to that temp-table in each object (CustomerSomething).
I never implemented it, but I still think it would be a reasonable thing to do.
First, let me say that my suggestion of wrapping the temp-table or PDS is not my recommended implementation, but just an effort to get the ROH (relational-object hybrid) folks to at least encapsulate the data.
Second, I also disagree with the idea of wrapping the data separate from the behavior. I think they belong together, so I would never create a class like this.
What I would do depends on the context.
For a single instance, I would create an object with properties, no TT or PDS. In it would be the behavior that applies to single instances.
For an arbitrary collection, I would use one of my collection objects to hold individual instance objects as above. This might be something like a dating service where the user can select 5 prospects from a browse for closer examination, i.e., the set is not the result of a query, but rather a one by one selection.
For a set which was the result of a query and where I expected to use it regularly and the set had some behavior, I am currently thinking that I would create a set object which wrapped a temp-table or PDS, which had suitable set behavior with it like searching on keys or what have you, and which had methods which would return an individual object when needed. One could also have a method to add an individual object to the table if that was appropriate.
If desired, this kind of set object could be made reentrant by simply not implementing any sense of "current", i.e., all methods would have to include the selection criteria with them.
Three different contexts; three different solutions, none of which are a mere data object.
In this approach, I think your first question just disappears because it doesn't apply to this structure.
The second question also disappears because the individual instance class doesn't need the temp-table and so the properties can stand on their own. The result set class wouldn't expose individual fields of the table. If one wanted to look at the value of a property in a specific record, one would pass back a single instance object and query the property.
Yes, I think the datasource is in the class that builds these objects, not in these classes themselves.
Your fourth question also doesn't apply here. One gives search criteria to the DA object which returns one of these classes. The search criteria are not in the result set, although one might have a need to return a subset of the result set in some cases. Normally, though, one would want to resolve that in the DA object if possible. Whether to implement currency or not is a separate question. I can think of places where it would be handy and places where I would avoid it. Given that the data is in memory, FIND NEXT is not really a different performance than a FIND by key, but one would want to have some form of way to iterate simply. I haven't thought about that a lot, but one option might be a method which returned a list of keys and then one could just work through the list. One advantage of this approach is that the list of keys wouldn't have to be complete. E.g., the result set could be the order lines for a given order and one could have a method to return the keys corresponding only to the lines which were still open.
I think your last question also disappears in this context. The collection provides a mechanism for managing loose groups.
First, let me say that my suggestion of wrapping the
temp-table or PDS is not my recommended
implementation, but just an effort to get the ROH
(relational-object hybrid) folks to at least
encapsulate the data.
I have illustrated the wrapping, to get the discussion started, since you didn't have time for it. The case was:
- you want to use a temp-table
- you want to wrap it (hide it)
Second, I also disagree with the idea of wrapping the
data separate from the behavior.
The example doesn't implement business logic, since that requires some more context. A full implementation of CustomerSomething will of course have behavior and more specific methods. The goal is to illustrate what issues to solve when you want to take this route.
I would like to invite you to start a new thread to illustrate working with "real domain classes", so we can keep the discussion clean.
I haven't thought about
that a lot,
I don't want to be rude, but it would help if you would be more concrete. Throw some code examples in. Just illustrate how you deal with 4GL constructs. Doing some sketching with real code is a reality check for your (implementation) architecture. It makes you realize why things need to be implemented a certain way.
When I have time to develop some example material, I will publish
it. Right now I don't have that time.