Can LINQ be compared to Progress' db contextual developm

To be brief, no.

That's what I figured.  Would be nice if it had a transactional framework to ride on top of.

When coming from a 3GL LINQ looks promising because it simplifies querying data (in which for ever).

When coming from the Progress 4GL (in this thread the better name than ABL), querying is just one asped. Certainly more programs do just query data. But most of the complex programs contain transactional processing. That's so much more integrated with the whole block orientation and error handling in the Progress 4GL that I can hardly see a competition between LINQ and the 4GL.

Over on the PEG, I and some others have been having an interesting conversation about relational data and OO.  Supplementing this, I have been having some very interesting exchanges with someone who is even more of an EOF than I am, but is someone whose opinion on UML and OO I respect deeply ... even though I don't always agree with him in terms of the application to ABL.  All of this will be leading to a whitepaper reviewing alterntive patterns which I hope to publish shortly, although I might have to do some benchmarking before I arrive at complete conclusions.

Point being that in some of the offline discussions we have been digging into the relationship between OO and the relational data model (RDM).  Traditional OO design and the RDM are really antihetical -- objects are a different way of organizing the universe than tables and columns, just like the old hierarchical databases were very different from relational ones.  Navigating objects happens in a fundamentally different way than one navigates in the RDM.  Originally, people expected this to mean that we would migrate from RDBMS to OODBMS, but that has largely not happened for a number of reasons including:

* RDBMS are performance leaders;

* Reporting is often done with SQL and third-party tools which need relational data; and

* Efficient and flexible tools for Object-Relational mapping have been created to simplify working with objects, but persisting in an RDBMS.

More recently, it seems that people are begining to realize that there might be a role for RDM data or at least RDM-like access in OO processing code.  Some of this shows up in using datasets to transmit data over the wire; some in efforts like LINQ to make it easier to query OO data in a more RDM-like way.

Our task ... should we choose to accept it ... is to figure out the best patterns for adopting OO in ABL which will still take advantage of the relational features of ABL.  For the UI, this is pretty clear, at least in the context of ABL GUI for .NET since the OO features of ABL have been well tuned (at least now that 10.2B will support generics) for supporting the requirements of using .NET classes (now we just need generics for ABL) and the relational aspects of ABL are well suited for creating the data sources to use with those classes.

What patterns we should be using in the business layer and how those should interface to the data access layer are less clear ... but I hope to be improving that clarity soon.

having some very interesting exchanges with someone who is even more of an

EOF than I am, but is someone whose opinion on UML and OO I respect deeply

What's an EOF?

-- peter

I was wondering the same!  End-Of-File doesn't quite fit!!

EOF = Extremely Old Fart

In terms of the main topic, I do find it slightly amusing that MS are 25 yrs after Progress, coming to the conclusion that some form of 'native' data-aware constructs in a language might be useful.  As Mike F. says, unfortuneatly for them it's more than just  querying the data, so I think it would take a completely different approach from MS to get anywhere close to what the ABL offers today (with relation to it's native data capabilities).

I was wondering the same! End-Of-File doesn't quite fit!!

Enterprising Oeno-File?

-- peter

Meaning I just put the bottles into neat racks and I'm not busy emptying the contents?  Nice try, but backwards!

BTW, Stan Kelly-Bootle ... anyone remember his Unix Review Devil's Advocate columns and the Devil's DP Dictionary ... has opined that one has to have been an IT professional for 50 years to qualify as a true EOF, but I think that is a trifle self-serving of Stan since his IT career started in 1955, i.e., there are very few people who could possibly qualify at this point.  I tend to think that 40 years should be sufficient, so that one has at least a chance to attain the status before retiring ... should one ever retire ... Stan is still writing his Curmudeon column for the Communications of the ACM.

Didn't it take Oracle until v6 (circa 1990 or so) to realize that row level locking might be useful?  (Has MS figured that out yet?)

Our task ... should we choose to accept it ... is to figure out the

best patterns for adopting OO in ABL which will still take advantage

of the relational features of ABL.

>

I hope it's NOT the mission: impossible, Mr. Hunt.

You may have noticed that all of those "impossible" missions got handled ....

Now, getting everyone to agree ... that might be a true mission impossible!

 
What patterns we should be using in the business layer and how those should interface to the data access layer are less clear ... but I hope to be improving that clarity soon.

This is a new challenge.  A non-procedural business rules layer would be beneficial but how would it fit into the native presentation (UI<>DB) model?

I guess the first question I  would ask: what pattern is the Progress model based on? http://martinfowler.com/eaaDev/PresentationModel.html

http://communities.progress.com/pcom/docs/DOC-14628

fixitchris wrote:
 
What patterns we should be using in the business layer and how those should interface to the data access layer are less clear ... but I hope to be improving that clarity soon.
This is a new challenge.  A non-procedural business rules layer would be beneficial but how would it fit into the native presentation (UI<>DB) model?
I guess the first question I  would ask: what pattern is the Progress model based on? http://martinfowler.com/eaaDev/PresentationModel.html
http://communities.progress.com/pcom/docs/DOC-14628

The Communities doc you linked to above sorta answers that question.

That said, we've done some work on Presentation layer code for testing the newer OO and GUI for .NET stuff, which uses the Supervising Presenter/Controller pattern (http://martinfowler.com/eaaDev/SupervisingPresenter.html). We're working on making that available (and yes, it'll be as-is).

-- peter

To me, working in an OERA compliant envirionment means that whatever you do for client UI is independent of what happens on the server, except for the possibility of a very thin, client-type-specific service layer.  I.e., solving the problem of what to do in the client is entirely seperate from solving the problem of what the rest of the system is like.  In particular, I make no assumption that the client is even ABL.