This thread can be a place to continue the Exchange chat session on OO and in particular strategies for data representation. (More threads welcome, of course.)
Is a script of the chat available somewhere?
.....
J. Sadd - PSC:
Hi, this is John Sadd from Progress, here to co-host a chat session called “To OO or not to OO”.
J. Sadd - PSC:
I had a lot to do with the design of the ADM2, which included a Version 9 attempt to make the language at that time act as object-oriented as was possible, and I’ve since written and talked a lot about the OE Reference Architecture, including how to think about implementing that with classes in OpenEdge 10.
J. Sadd - PSC:
With me is Thomas Mercer-Hursh from Computing Integrity, who got up at an unreasonable hour in California to join us. Thomas is a well-known and famously devoted contributor to OE discussions of all sorts, including many on object-oriented design and how to use or not to use some of the ABL mechanisms we provide to represent data as objects. Hello, Thomas.
T. Mercer-Hursh - Computing Integrity, Inc.:
Hello John. John and I have a long running debate on the best way to represent relational data in OO, and we could continue thhat, but lets see what the audience would like to hear.
J. Sadd - PSC:
The chat title covers an impossible range of potential discussions. We could make a few points about the value (and challenges) of programming with classes in ABL.
J. Sadd - PSC:
Or we could make a few points about the challenges of representing relational data in an object-oriented environment. Please join in and let us know what you’d like to talk about for this brief session and beyond.
J. Brock - Keystone Systems:
I'd like to hear about recommendations for data movement, such as temp tables / datasets vs. classes and collections
S. Prinsloo - Quality Business Consultants:
Relational data is of great interest for me.
R. Bruintjes - Medeco Security Locks:
I'm voting for how to represent the data in an OO environment.
J. Sadd - PSC:
Well, the ProDataSet is a powerful relational data object that can hold complex data in relational form. You can pass it around between sessions as a single data object.
J. Brock - Keystone Systems:
and how that may change with newer features for reflection in the ABL
J. Sadd - PSC:
But you can’t pass a “true” object (class instance) as a parameter to another session, so the data and the behavior that supports it become independent.
T. Mercer-Hursh - Computing Integrity, Inc.:
Moving relational data is a key of the difference in our approaches. John likes moving around PDS and I like encapsulating them in objects and moving the object ... not acroos the wire, but within the session.
J. Sadd - PSC:
Encapsulation is fine, and I'd agree that you shouldn't expose tt and DataSet structures, and that's fine within a single session.
T. Mercer-Hursh - Computing Integrity, Inc.:
To me, sharing a PDS definition across classes is a major violation of encapsulation, while enclosing within a class hides the implementation from everything else.
J. Brock - Keystone Systems:
would that be one dataset per object, or a shared dataset with objects that access it with a key (sort of like the multi-tenancy talk just now)
G. Morin - Groupe Canam:
Thomas, when can we expect some samples of your OO approach ?
J. Sadd - PSC:
Agreed on not sharing PDS definitions across classes (except protected defs within a class hierarchy.
J. Ledbetter - Tugboat Software:
Isn't the PDS itself an ecapsulated object? No, it's not a Progress.Lang.Object but it is a stand-alone object with properties and methods.
T. Mercer-Hursh - Computing Integrity, Inc.:
One dataset per object can get you into the Too Many Temp-Tables problem, which is why I prefer properties to one row temp-tables.
J. Sadd - PSC:
You can restrict access to the data def within a session and then pass the PDS as a data object to another session that does the same.
T. Mercer-Hursh - Computing Integrity, Inc.:
New whitepapers and code are in the works.
J. Sadd - PSC:
And dynamic handle parameters allow you even to do that without sharing a static def between say client and server.
T. Mercer-Hursh - Computing Integrity, Inc.:
I don't see the PDS as a proper object because it has no entity behavior.
J. Brock - Keystone Systems:
I was just going to ask John how entity behavior is provided. do objects handle an entire dataset, or one row? "row" meaning one entity, because some fields may require multiple rows
T. Mercer-Hursh - Computing Integrity, Inc.:
For me entity objects are single instances and set objects are for entire datasets.
G. Crawford - Innov8:
Thomas - if all the fields are properties do you have a factory that generates that? Otherwise how do you handle inevitable changes in the table down the road?
J. Sadd - PSC:
Re: entity behavior: true enough. It's just a data storage mechanism (with some relation info added in). So you have to identify what behavior is truly universal to the object and make it available everywhere the data is used, and which behavior is for instance only needed on the server side because that's where the BL is run.
T. Mercer-Hursh - Computing Integrity, Inc.:
Code generation is certainly your friend, but ultimately, keeping the code and DB in sync is just a part of development, unless you are crazy enough to use LIKE.
J. Sadd - PSC:
[To: J Brock] You probably want different behavior on client and server anyway. Server behavior is encoded in a Business Entity or business object os some kind, which manages the serious business logic.
T. Mercer-Hursh - Computing Integrity, Inc.:
With the PDS passing approach, one has encapsulated the data and behavior separately ... not a plus in my book.
J. Sadd - PSC:
When the data is used on a client you don't want all that behavior anyway and probably can't use it without the db connection.
G. Crawford - Innov8:
John - re: entity - if it's just data storage, then is it really an entity or just a data object? Shouldn't an entity be based on the application's business flow and an encapsulation of the requirements for the process? To me a data object is then something at a much lower level than an entity.
J. Brock - Keystone Systems:
John, would your view change if objects could be passed between sessions, or would you still prefer separate datasets?
T. Mercer-Hursh - Computing Integrity, Inc.:
Note too that most of what I say is about the server since I am inclined to treat the client as something independent and quite probably not ABLin many cases.
J. Sadd - PSC:
We all need to keep in mind that no matter how you represent the data you can't pass the object (i.e. rcode holding both data and behavior) between sessions anyway. You have to extract the data somehow and pass it into another object on the other side.
M. Ormerod - Progress Software:
I think you also have to be careful not to disregard the strengths of the ABL, especially as a data-aware language, and that many OO/Class based initiatives are all built around trying to fix that deficiency is traditional OO languages. (Such as ORM)
G. Crawford - Innov8:
Thomas - code generation can be a friend, but it can also be your worst enemy. I wasn't thinking along the lines of something like a development time generation but a run time factory.
T. Mercer-Hursh - Computing Integrity, Inc.:
Yes, but passing an object across the appserver boundary is only meaningful if the client is ABL.
T. Mercer-Hursh - Computing Integrity, Inc.:
Factories have their place ... and for code generation read MDA
J. Brock - Keystone Systems:
Thomas, are you using openclient on the client side? How are you passing objects to the client?
J. Sadd - PSC:
[To: J brock] Again, regardless of data representation, you need different logic/behavior in different places (client/server). So even if I could I would not want to pass a business object to the client with a lot of BL that the client doesn't need and probably can't even execute.
T. Mercer-Hursh - Computing Integrity, Inc.:
Mike, yes, we do want to use the strengths of the ABL in data handling ... we just want to encapsulated it.
J. Sadd - PSC:
The PDS is just a good mechanism for mapping potentially multi-level relational data to a single data object that we treat intelligently within ABL.
T. Mercer-Hursh - Computing Integrity, Inc.:
Indeed, John, even if the client is ABL, the object there may be something very different than a true entity object like on the server.
J. Sadd - PSC:
And note Thomas's note about the client" if you presume a non-ABL client then your data representation choice becomes more flexible.
J. Brock - Keystone Systems:
John, so to borrow some terminology, you are treating the dataset as a bean and/or collection?
G. Morin - Groupe Canam:
Isn't using ABL data-relational strengths means losing OO strengths ?
M. Ormerod - Progress Software:
Sorry for coming to this late (I had some questions to answer), but has the general queston been asked as to whether going forwards people will write predominantly OO/Class based code as opposed to typical procedural ?
J. Brock - Keystone Systems:
I guess I would ask why you wouldn't prefer a dedicated data object which can hide the implementation of the underlying data
J. Brock - Keystone Systems:
that representation would be the same on both the client and the server after all
T. Mercer-Hursh - Computing Integrity, Inc.:
It seems that good practice these days would be to assume that the client could be any technology.
J. Sadd - PSC:
But if you want to take advantage of, say, GUI for .NET, then there are big values to representing data on the client as tt's or PDS's as well (ProBindingSource). To some extent this just reflects our own biases in how we've implemented things, of course.
J. Sadd - PSC:
To Mike: No, we got pretty quickly onto the thread of how to consider representing relational data in an OO app.
M. Ormerod - Progress Software:
THM/John., which is why we suggest the use of a service interface to handle the specific requiremsts of each possible client type
T. Mercer-Hursh - Computing Integrity, Inc.:
Using PDS and TT doesn't have to lose any virtues of OO ... if one keeps them encapsulated!
J. Sadd - PSC:
Yes, I don't mean that using a TT or PDS implies/requires a particular ABL-based front-end, since of course you can translate TT/PDS data format in many ways (including XML and JSON), just that if an ABL client is one representation you get many benefits from that.
T. Mercer-Hursh - Computing Integrity, Inc.:
Right Mike, and with that interface, the needs of the client should not influence data representation on the server.
M. Ormerod - Progress Software:
sure (to u both)
T. Mercer-Hursh - Computing Integrity, Inc.:
What ... not taking sides?
J. Sadd - PSC:
Yes, T M-H and I don't disagree that it's good to keep your data encapsulated. Within a session I would not simply open up TT and PDS defs (imperfect implementation examples perhaps notwithstanding).
P. Magnay - Progress Software:
The choice of procedural, record-centric programming versus object oriented approaches can be difficult to fathom. I definitely recommend researching some ORM patterns like the Data Mapper and the Repository pattern if you are inclined more towards the OO approaches.
G. Morin - Groupe Canam:
Encapsulation is only one feature of OO. How to do abstraction and polymorphism at the entity level using PDS/TT is not clear to me.
M. Ormerod - Progress Software:
no, I'm agreeing with you both. You should optimize the data for the client via an SI, and that should not ultimately influence the standard data def you use of the server
J. Brock - Keystone Systems:
M. Ormerod: but internally what is your recommendation?
T. Mercer-Hursh - Computing Integrity, Inc.:
If the PDS or TT is encapsulated, I think the outside can have any OO characteristics you want.
J. Brock - Keystone Systems:
is Progress going to be adding better support for objects like built-in serialization/deserialization, etc, to facilitate transfer?
T. Mercer-Hursh - Computing Integrity, Inc.:
Do you want to serialize the object .. or just the data?
J. Brock - Keystone Systems:
maybe native collection classes for performance?
J. Sadd - PSC:
J Brock: Do you really want to serialize r-code between sessions when you pass an object? You can of course already serialize the data in many ways (native TT/PDS, XML, JSON, comma-delimited list... :-)
M. Ormerod - Progress Software:
It's what works for you, your code, your app. The main thing is to get the architecture right so you get maximun code re-use, have clearly defined services and ideally standard business data definitions. How you choose to implement is then a choice. There is no right or wrong in any of this
J. Brock - Keystone Systems:
no not r-code, I meant more like a write-xml procedure for objects
G. Morin - Groupe Canam:
[re: P. Magnay] I don't see how one can implement ORM patterns in OOABL without having collections in the language.
T. Mercer-Hursh - Computing Integrity, Inc.:
What would a native collection class do for you that you can't do better with a temp-table?
J. Brock - Keystone Systems:
personally I would like a hash table implementation for O(1) lookups
J. Sadd - PSC:
J Brock: SO you mean serializing all the block-0 - level data in an object automatically, not just what you stuck into a tt or PDS? Some would definitely like that; I think Thomas does something similar "by hand" to move an object effectively to another session.
S. Prinsloo - Quality Business Consultants:
Assuming that the r-code must exist on both sides, serializarion means to me the ability to stream the storage area of the instance. Remember, if I create multiple instances OE load the file once and create seperate data segments for each segment.
J. Brock - Keystone Systems:
that could be shoehorned onto a temp table I suppose, but I see a lot of advantages to polymorphism, etc, where I could say Collection x, and change the implementation transparently
P. Magnay - Progress Software:
The OO implementations I have worked on will use both TT/PDS programming and object instances. Even ORM patterns need to work with tables and records. It's all about abstraction and encapsulation.
J. Sadd - PSC:
Before we lose the floor, we'd like of course to continue the discussion beyond this brief intro,
J. Sadd - PSC:
We'll create a thread or more on the Communities forum area to continue elements of this discussion at
http://communities.progress.com/pcom/community/psdn/openedge/oopractices
T. Mercer-Hursh - Computing Integrity, Inc.:
Also check OE Hive and my website at cintegriy.com for coming whitepapers and code. You can reach me directly at thomas@cintegrity.com
P. Magnay - Progress Software:
G. Morin: It's no problem creating your own collection classes.
T. Mercer-Hursh - Computing Integrity, Inc.:
Look on OE Hive for my 10.1A version of collection classes.
M. Ormerod - Progress Software:
Well, since you all have many things to say, keep an eye out for a new initative I'll hopefully be starting soon in which you can ALL participate
M. Ormerod - Progress Software:
From design collaboration to coding
G. Morin - Groupe Canam:
[P. Magnay re: It's no problem creating your own collection classes.] It has to be implemented with a TT, which adds too much overhead.
J. Ledbetter - Tugboat Software:
Too much overhead in what way?
T. Mercer-Hursh - Computing Integrity, Inc.:
But, it adds a lot of power too. Have you benchmarked it and found a problem? The only issue I know is the TMTT problem if you create collections with objects that contain TT, but that would be an issues with native collections too.
J. Ledbetter - Tugboat Software:
We use TT's for collection classes. Unless we try populating the collection with *many* objects, it's quite speedy and convenient.
G. Morin - Groupe Canam:
One example is if you have a set of Orders, each one having a set of OrderLines. This create the TMTT problem that Thomas mentioned
T. Mercer-Hursh - Computing Integrity, Inc.:
Jeff, what is "many" and is the issue there if the objects don't have TT themselves?
J. Ledbetter - Tugboat Software:
Many = apprx 1k. The objects themselves do not have TT's.
T. Mercer-Hursh - Computing Integrity, Inc.:
Right G.Morin, but the core issue there is TMTT. Even if the order header is properties, if you have one or more TT inside, then lots of orders will be an issue regardless ... I think I have a solution to propose, so stay tuned.
J. Ledbetter - Tugboat Software:
We chose another route for that particular use-case so it's no longer a problem. We try to limit our collection class usage to smaller object collections.
T. Mercer-Hursh - Computing Integrity, Inc.:
Your usage context, Jeff, is a bit different than the general ABL application.
J. Ledbetter - Tugboat Software:
Yes, somewhat. Are we getting kicked out now? :-)
P. Magnay - Progress Software:
G.Morin: Collection classes don't have to involve great overhead if you implement the ORM patterns intelligently. I certainly do no advocate loading every record from a TT into a collection.
G. Morin - Groupe Canam:
Why not ?
P. Magnay - Progress Software:
Because of the potential overhead. Only load the records into the collection that you need.
T. Mercer-Hursh - Computing Integrity, Inc.:
Of course, sometimes you need a lot of them...
G. Morin - Groupe Canam:
I mean, not in all cases, but there is certainly cases, expecially complex with business logic, where working with class instances instead of tt records gives a lot more powers
G. Morin - Groupe Canam:
My point is why this overhead exists in ABL ?
P. Magnay - Progress Software:
If you're using lots of records at once then use the power of the ABL to process those records.
J. Ledbetter - Tugboat Software:
I think the idea is to find a healthy balance between traditional AB and OO. I am not so sure that one object-per-record is the right approach though. Can't you have an object that encapsulates the PDS or TT and returns an single instance of the object type that you need?
G. Morin - Groupe Canam:
so, the power of ABL is not OO :-)
P. Magnay - Progress Software:
That is not what I said. :-)
T. Mercer-Hursh - Computing Integrity, Inc.:
Jeff, that is exactly what I advocate ... use the strengths, but encapsulate to preserve the OO advantages.
T. Mercer-Hursh - Computing Integrity, Inc.:
And Guillaume .. ABL is *more* than OO.
P. Magnay - Progress Software:
Yes. You can leverage the power of both.
J. Ledbetter - Tugboat Software:
It would be nice for PSC to provide this type of OO framework instead of each rolling his ownn.
T. Mercer-Hursh - Computing Integrity, Inc.:
Have we bumped the Netherlands PUG off the schedule?
G. Morin - Groupe Canam:
Yes, but I think some old concepts enter in conflict with new OO concepts.
P. Magnay - Progress Software:
Yes. Where are the guys from the Netherlands?
R. Kelters - Flusso B.V.:
Here we are
P. Magnay - Progress Software:
OK. Over to you.
T. Mercer-Hursh - Computing Integrity, Inc.:
We just need to work on finding the best synthesis. That is an opportunity, not a problem.
J. Ledbetter - Tugboat Software:
That's the beauty G. Morin.. You can choose the style appropriate for the task. :-)
R. Kelters - Flusso B.V.:
Thanks, what's the best way to start this?
R. Kelters - Flusso B.V.:
.. or stop?
T. Bascom - White Star Software:
Offer free beer!
J. Palmer - CAL Software:
Oranjeboom all round?
R. Kelters - Flusso B.V.:
Actually Heineken is today's flavor, alright?
J. Ledbetter - Tugboat Software:
You guys hit the sauce early. ;-)
J. Palmer - CAL Software:
it's after 5pm in Netherlands
R. Kelters - Flusso B.V.:
Well, it's passed 5 o'clock over here
J. Ledbetter - Tugboat Software:
Well, booze-away then. :-)
P. Magnay - Progress Software:
Richard, why don't you start by asking if there are any topics that interest the Netherlands PUG members?
... with a little overlap of the Netherlands PUG session that followed ...
My PUG Challenge presentation on this topic
http://www.cintegrity.com/content/Patterns-Managing-Relational-Data-OOABL