Advice form the young at heart... Design program closer to

I can recommend autoedge thefactory. You would need some time to get it to work and understand how it works. To me it proved a valuable investment of my time. See for an introduction  community.progress.com/.../879.welcome-to-the-complete-autoedge-kit.aspx you can find code at github.com/.../autoedgethefactory

but of course Peter can provide the most useable links. These were quickly grabbed.

  You can see oera as a separation of concerns principle (robertcorvus.com/separation-of-concerns-principle) at a high level. "The value of separation of concerns is simplifying development and maintenance of programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently.

Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections."

  Of course oera is not much more than a rebranding of principles described before, outside of the progress world. I have no idea where you can find a white paper going a bit into depth about oera. This paper from outside the psc world could give you an idea: www.ambysoft.com/.../persistenceLayer.pdf (doubtless much more to be googled).  

 So if you separate your application into the layers used in the oera you should be able to switch UI's more easily / connect different UI types simultanuously to your backend. Have different programmers/teams work on different layers more or less independently (using the api of the layer below that for the rest can be regarded as a black box). Allas you will find the progress database, as db type, tightly tied to your dataaccess layer when you use it's propietory (but very handy) query language. But at least only to that layer if you implement the separation well. It would be nice if we could replace the db easy with f.e. an open source db like postgresql.

--

Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

I appreciate both answers as being dedicated lot of time to this...

I'll do as told.

Thanks a lot!!!

Hey Octavio, doing what you've been told might work but experimenting on your own is at least twice as fun... so whatever floats you boat will do.

Watch out for those many layers out there, if I'm to rant about OERA would say there should be better ways that just passing around datasets - between 2-3 layers on back-end (DA, BE, services) move that to the client and add up some extra topping to the cake on that side :)

I've seen a large number of ISV's going OERA with some sort of desktop UI (fat or webclient, almost the same one might say) and then they just use the same dataset-centric approach when they want to do web/mobile... the excuse is always the same, reuse business logic.

The posts were not telling Octavio what to do, maybe Octavio did not mean what we read?

 But what are these better ways Marian, and is there an exampleframework where those ways can be seen? And why are those ways better, you have any links to more info / discussions?

 I don't know if you know autoedge, but Peter developed an ingenious way to "pass the datasets around":

community.progress.com/.../990.oeri-service-message-infrastructure.aspx

 (some more about autoedge components can be found via community.progress.com/.../default.aspx by the way, Octavio, f.e. aboiut InjectABL).

----------------------------

Searched my pegmail, I suppose you had orm in mind Marian? You already built an alternative or do you still have an excuse? ;-)

Marian Edu via peg.com 11/26/10

Pe 11/26/2010 12:52 PM, Mike Fechner a scris:
>> I'm kinda favouring the ORM approach cause introducing a DL will also
>> take away the database structure and with it the strong-typed data
>> access,
> The "community" is still waiting for a working model of that - also to compare the performance to a ProDataset / Temp-Table based solution.
>
> Do you have something the you can share?
I wish I had, I thought I'll take a break from all that OERA layers and
enjoy the Java beauty for a while but it looks like I'll still need some
data access layer for the 'fake' JDBC proxy I'm playing with... nothing
to share so far though :)

> -----Ursprüngliche Nachricht-----
Im Auftrag von Marian Edu
> Gesendet: Freitag, 26. November 2010 08:37
> An: peg@peg.com
> Betreff: Re: AW: What is a DA layer anyway? ( was Re: Betr.: overhead layered application)
>
>
>> And not to forget, that it's the only structure of it's kind that has built in ability to be passed between different tiers. Browsing a list of customer records is a common concern. Data needs to get to the UI.
>>
>> Temp-Tables are not dead. And will not be dead in the next OE release either.
>>
> Definitively, I think we can even get Dr. Hursh to agree on that assert
> unless in a near future release we'll be able to pass real objects
> between tiers and we all switch to the ORM approach :)
>
> While it's true that very often one do need to pack a set of records and
> pass them as a whole (most often for client display) and a 'set
> oriented' fetch do have it's place in a DA layer but there are other
> cases where the temp-table need not to be filled with all required
> records at once and a sequential access is preferred... as for computing
> calculations like total, average, etc. One 'extreme' example of
> performance penalty induced by those dataset oriented DL is 'delete
> cascade' when deleting a record from parent table the DL might need to
> load all corresponding records in child temp-table, delete them on-site
> and save changes to the database as the DL are barely based on get-changes.
>
> I'm kinda favouring the ORM approach cause introducing a DL will also
> take away the database structure and with it the strong-typed data
> access, if it's exactly the same data structure as in the persistence
> layer or it's mapped somehow I won't mind as long as I can 'see' somehow
> what the structure is. However, there are times when the pure object
> approach does not come in handy and the DL should provide a somehow
> lower lever interface (the core part of Hibernate).
>
> --marian
>

Thanks (Stefan) Agent 008.

Yes, you were able to see what I found, I asked for examples, and instead got some fundamental principles.  So I went after AE thefactory  and began there, but I'm seing that It will take me a lot to get where I need to go, as the first lines on reading about thefactory, diverged me to DI and IoC (Dependency injection and Inversion of Control) and will need to land the litle OO I have on ABL territory (I already have "How I learned to love OO " and related videos, white papers, and stuff)....

Also check my next post about BE  "create" and "update" methods.

Instead??!  You have got your pointers to examplecode Octavio, so you got what you asked for. Behind that examplecode are principles. Code without principles you can find on every dunghill. "There is no such thing as a free lunch."  Google for this last sentence, fold your hands, pray and expect a rebirth. ;-)

Good night, S.