It's refreshing to see folks with ABL familiarity thoughtfully discussing this topic - even proposing (and using) patterns.
Object/relational mapping has been a discussion topic for many years - although often focused on persisting an object hierarchy in a relational database rather than developing an object hierarchy to manage a relational database. Given a long history of a well-performing 4GL, it often feels somewhat treasonous to give up a straight-forward FOR EACH or FIND for an OO construct.
Undoubtedly, finding the right balance between direct database access and OO constructs is an ongoing pursuit that may have to be judged on a case-by-case basis. Perhaps the real performance killer is the paralysis of analysis. ;-)
FWIW here are a couple more interesting (non-PSC) resources on the topic of object/relational mapping:
Well, you bring up some interesting points: ORM and the "loosing" of FOR EACH and FIND.
Usually every discussion about OO models turns around the idea of having two incompatible models: the OO model for the application logic and the relational model for data persistency, working togheter by means of a ORM "bridge".
Progress is givin us the posibility of truly joining both models, instead of "bridging them", by means of ProDataSets and Temp-Tables (as we did with NSRA). This join of models gives you the benefits of having an OO structure, error handling, overriding, inheritance, etc. without loosing the ability of doing FOR EACH nor FIND, not over the Database but over Temp-Tables.
The Model-Set-Entity Pattern does not goes that far, it is still an ORM.. I will call it an "advanced ORM", because is giving you more control over the mapping, and is taking some advanteges of the use of ProDataSets and Temp-Tables to be more "efficient" in object managment.
The model is "close" to a pure OO model (as CI model proposed by TMH), but has some "breaks" of OO in the concep of Sets (as far as I can see - not so far by the way !!).
I don't agree with this kind of model, where you loose the ability of doing a FOR EACH or a FIND, for ABL, because I beleave they are "excesively theorical", I really don't think this models are productive enough nor efficient enough (and there are no implementations to prove me wrong!), compared to existing OO models for other languages, to worth the effort of implementing such model.
I think "Progess people" is somehow affraid of changing to an OO developing model because they feel you are loosing the "ABL power" of FOR EACH and FIND, with nothing to compensate this loose. I feel this too when I see this kind of model... and I start working with ABL with version 10.1C allways in OO.. so I think someone that has been working with ABL for longer time must be really worried about this.
I have constructed an application for our business based on the OERA. We now wish to use the GUI for .Net tools / controls and re-write the front end. I am fairly new to OO principals and patterns but have just started the re-write using an MVC pattern. Having read your posts here, I'm very interested.
If, as a user of our (newly written) application, I have a new order in process, switch to a datagrid view of some other set of updatable orders, and open yet another view of customers / orders, will multiple entity sets represent the context for the work being done? Will there be one instance of the OrdersModel?
Do the BE's in your diagram contain the business logic that the OERA implemented on the appServer or mostly a collection of get/set properties?
Hi Guillame, You seem not to agree to the model proposed and indeed you are giving relevant remarks and are refering to other patterns. Could you give us your image of a proper pattern for Progress and its OO functions.
Hi Thomas, you seem to agree with the principles of this framework. Are you designing apps using Progress/Gui .Net and OO principles, and what pattern have you adopted for developing you business applications ?
Could Mike give us his feedback aswell.
For a preliminary read on my reaction to this pattern and others, see http://www.cintegrity.com/content/Patterns-Managing-Relational-Data-OOABL . There are whitepapers in process which will develop this topic in more detail.
There is a very important watershed in these patterns between those which focus on holding data in a ProDataSet versus those which focus on a more traditional OO model in which the data and behavior of an individual instance is encapsulated in what I call a PABLO, Plain ABL Object. The PDS has natural appeal because of its power and 4GLness, but I personally find it presents a number of obstacles to following OOP principles, principles which are more easily preserved with PABLOs.
Which said, if you are going to come down in favor of the PDS, the PPS M-S-E pattern has certainly been thought through thoroughly and has some features about it which preserve ... or should I say restore ... some OO-like patterns which are missing in other approaches.
For me, none of this has anything to do with .NET since none of it has to do with any particular form of UI. This part of the pattern is about what happens on the server. To me, what happens in the client should, at most, be reflected in a service class on the server which adapts to the needs of the particular client type. An ABL GUI for .NET client isn't going to use a pattern like this since it has no real data layer, only a facade to the data source on the server. From the little I know of ABL GUI for .NET clients, there appears to be a role for PDS and TT as local data sources, just as I think there is a role for them in the data layer in my pattern.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
An ABL GUI for .NET client isn't going to use a pattern like this since it has no real data layer, only a facade to the data source on the server. From the little I know of ABL GUI for .NET clients, there appears to be a role for PDS and TT as local data sources, just as I think there is a role for them in the data layer in my pattern.
Exactly. In order to get ABL data into a .NET Grid and automatically synchronise Input Fields you'll need a ProBindingSource. The ProBindingSource can talk to a QUERY, a ProDataset or a BUFFER. Not to an object directly (the Alternative would be binding to an Array of .NET objects which is not attractive at all inside the ABL).
So for a GUI for .NET thin-client there needs to be a TEMP-TABLE based representation of the data. The question is where to build that when the backend does encapsulte data completely in classes and forbits all access to the tables directly (well, there might not even be a table as in TMH's PABLO). I doubt that turning OO wrapped data into an XML representation of data just to turn that into TEMP-TABLEs and ProDatasets on the client is the best choice. I rather tend to send ProDatasets between client and AppServer. When all data is wrapped in objects the responsibility for creating TEMP-TABLEs and ProDatasets to send to the ABL based clients is on the Service Interface.
I cannot really disagree with this model since no real details have been revealed yet.
However, it all come down to if you are comfortable with using PDS to represent your data in your OO business model. I am not, PDS and OO are conflicting paradigm, where mixed together result in some kind of complex hybrid model, where some OO features and simplicity are lost.
I must confess that I still have more questions than answers regarding an OO architecture in OE.My opinion is that OE is not yet ready for a real productive OO architecture, for its lack of performance and features.For a comparison, take a look at the upcoming .NET entity framework 4.0. OE is FAR behind all this, still arguing on the requirement of collections in the language...
I hope somebody proves me wrong.
Thomas Mercer-Hursh upcoming work looks really promising, and I hope this will trigger great interest in the community, so PSC put more emphasis on the OO "server side", instead of the GUI for .NET....
I will say, Guillaume, that there are parts of this pattern which correspond very well with OO thinking ... sort of. But, I agree with you that there are other parts which don't fit with the way I think OO should work. So, there is a watershed question which people are going to have to ask themselves. PDS are very appealing tools in the ABL arsenal and there are certainly ways in which they can make life easier. But, they are also very relational in concept. Some are going to say "So what, take the best of both worlds!" And, I don't know that one should reject them out of hand, just on purist grounds. If one is going to reject them, it should be for one of two reasons:
1. One has something better; or
2. One can identify ways in which this pattern does not conform to OO design principles and one can identify ways in which there is a significant loss of the benefits one would normally get from OO.
Really, of course, one should have both.
Given that via this pattern, the PDS is an internal representation of data that is encapsulated within an object class, I am still having trouble understanding some of the points being made here.
This is not a perfect pattern - none are. And there are definitely some improvements that can be made (*are* being made, in fact) and the input from this forum has helped identify some of those improvements.
But I am still don't quite understand which particular OO fundamentals and/or principles are supposedly being compromised by this pattern. Perhaps you guys could be a more specific.
Perhaps you could provide more specifics of this model
OK. That's one response that identifies no specific OO fundamental/principle being broken by the pattern. Anybody else?
I *will* be going into more detail ... on both the good parts and the parts I don't like ... when I get the whitepapers out. I am finding a need to prepare some background materials for the discussion, so it is taking me longer than I hoped, but I think the background stuff will be useful.
One of the problems here, Phil, is that there isn't really enough info published by which to make a detailed analysis. You and I have had enough exchange that I feel like I have some understanding of what you are doing, but the fruits of that discussion have not yet been published.
Which said, I think that there are some valid concerns which one can have even without that detail. Certainly, a PDS is a very relational view of the world. OO is not a relational view of the world. In non-ABL systems, the relational and OO issues are resolved at the boundary in the OR mapping layer. Pushing that relational view all the way into the business layer seems to me to be a valid suspicion that something other than real OO thinking is going on. As I have said, one can think that purity isn't required or even optimum, but you have to admit that there is a huge background of thinking about why traditional OO design principles are a Good Thing, so there is a good prima facie reason to question.
To forecast a bit more specifically, there are two points which I could bring forward without getting into a lot of detail:
1. Fundemental to the OO paradigm is encapsulating data and behavior together. Unless a TT is composed of objects, it is inherently just data. If the data populates an object in order to interact with it, then you have an inherent issue in having two copies of the data, one in the TT and one in the object. You address this issue in M-S-E by having a business entiry object which has behavior and which drills through to the TT to get the data. That is certainly a better solution than some I have seen and it ends up having some nice OOish things about it, but it does mean that you have violated normalization by having the same attribute available on two different objects (although, yes, I recognize one is not very usable because it requires a key which only the BE possesses) and it means that the data and behavior are only simulated as being together. I'm not going to say that this alone is a fatal flaw by any means ... indeed, I complement you on how good parts of it end up looking like a solid OO pattern, despite the unusual implementation. I do think you have to recognize, though, that it is a reason for a strong OO traditionalist to get very nervous.
2. I think that one has to recognize that there is an inherent issue about applying generalization and specialization using a TT and especially a PDS. If entity data in a superclass is in properties, then a subclass can add properties with no problem. With a TT, one has to start adding child tables and that certainly complicates creating the BE from that base. Make it a PDS with two levels and the required data structure can quickly be far from trivial. Add in the behavior, and it is a bigger problem yet. Add in some delegates which have their own inheritance tree and it can quickly become a nightmare ... and yet the traditional OO view of this same data is simple, elegant, clean, and has all the benefits of separation of concern one would like to see in an OO model. I know that you think you have addressed this issue by the use of the Decorator pattern, but to me that is far less clearly and solidly structured than solving the problem with generalization and delegation. I don't doubt that you make it work and, to the extent that you are creating the code with model-to-code technology, it is even probably pretty reliable, but I can't help but think that there must be a better way since it seems to torture the very simplicity and directness which I would expect to get by going with OO.
You do understand, don't you Phil, that it is hard for Guillaume to be specific in his criticism because he doesn't have much detail?
That doesn't exclude him thinking that there are things which are not OOish about this ... starting with sticking with the relational data model in the BL.
Again, you use the phrase: "traditional OO design principles". What are these principles you are alluding to? Which of these principles are being commpromised by the pattern?