Data abstraction

You can as well have the DATA-SOURCEs do the abstraction (to a certain point) by using field name mappings and joined queries as their source (instead of buffers). That would leverage all the power of the ProDataset and it's supporting objects.

When you do the abstraction (just) with an object - an not in it's contained TT/PDS, in that object (your main place for BL) the view on the data there and in the outside world would be different. That may get confusing.

Also at some point you need to get that data into an UI (when your application is actually used by human beings). If you pass the TT table to the UI and it does not have this abstraction on fields and calculated fields, you can't show those fields in the UI (Browser or Grid). When you solve the abstraction using objects, you will have to create a second temp-table for the UI which will create overhead when dealing with large data.

Houston, I see last weeks threads starting over again...

Thanks!

Just reviewing the PDS manual and it does indeed specify that datasources can be used to map field names between temp tables (PDSs) and the persistent database.

Thank you

This is what I've been looking for

Woo!

Just got my first example working with temp-tables named differently from the database tables and using the dataset "FILL" method

Thanks!

Data-sources, bloomin hard to work out how to get them going properly but powerful once you've got it

You can take it one step further and put the mapping information in a repository. Then you can create a single generic program that dynamically generates the datasets and datasources from this information.

Talking about abstracton

Ooh, are there any resources on this?

Not that I'm planning on making revolutionary changes at the moment but I like to know what's available and what's out there

Thanks!

It is probably worth stoping for a moment to consider the point of this abstraction.  If you have complete control over the DB, then there is no reason not to make the DB and the OO model match up nicely.  In fact, most of the principles of good OO design, e.g., separation of data between superclass and subclass have direct parallels in principals of good RDB design, i.e., echoing that separation by putting fields in separate tables.

So, the real point here is to have a line in the sand where there is DB on one side and OO model on the other side.  With that conceptual line, everything on the OO side is working with the same, consistent model and it is a model which you will naturally make "right".  If you can fix the DB to echo that model, so much the better, but if you can't, then you have a place where you can deal with any mismatch, e.g., if the DB needs to remain the same for a while to deal with existing legacy code.

We are doing this in our application but unfortunately I cannot put that code in the public domain.

It is not rocket science and I can tell you that it works well.

The first step to doing something generic is to do enough concrete things so that you know what the options are.  I personally am rather tepid on dynamic solutions because they obscure the analysis.  I would much rather do model to code generation.  Then, one can change the model and get new code quickly or change the templates and get new functionality universally, but the code itself is always concrete and analyzable.  Moreover, I think this approach is more susceptible for special requirements in special cases which do not then burden all instances with that special code.

tamhas wrote:
The first step to doing something generic is to do enough concrete things so that you know what the options are.

I personally am rather tepid on dynamic solutions because they obscure the analysis.  I would much rather do model to code generation.  Then, one can change the model and get new code quickly or change the templates and get new functionality universally, but the code itself is always concrete and analyzable.  Moreover, I think this approach is more susceptible for special requirements in special cases which do not then burden all instances with that special code.

My position is quite the opposite. I hate to generate and maintain tons of code that is similar for 95%. My motto is to only code exceptions.

But we have gone over this before.

My motto is to only code exceptions.

Mine too ... I just do it with generation instead of dynamic code.

The point of it at the moment is for me to add to my knowledge of what is available through Progress.

TBH we probably (more like definitely) won't be doing anything before we get some sort of advisor in to help us.  But I don't want them to get here and me not know what they're talking about.

Plus, I like to learn new things all the time if possible (especially if it's relevant to what I'm doing).

But I don't want them to get here and me not know what they're talking  about.

Of course, if you do know everything they are talking about, then you won't be getting your money's worth, will you?

Just teasing ... it is great to keep trying to figure things out and, you are right, the more prep you have done, the more ready you will be ready to listen.  But, I also wouldn't look at a mentor as a one shot visit either.  I'd think about it as someone who shows up, gets acquainted with your situation and interests, gives you some initial direction, and then continues to be available for mentoring.  That mentoring can be an e-mail, phone conversation, WebEx, or another visit depending on the topic and scope.  In many cases, a series of short, focused interaction when needed will do a lot more than and extended, in person exchange.

Also, I'd suggest that moving to OO is just a component of a larger strategy and plan which the company should have and I recommend that companies get that big picture clear before they start working on details.

http://www.cintegrity.com/OOAD

http://www.cintegrity.com/Strategy