Your view of development: The journey of separation - Forum - OpenEdge Development - Progress Community

Your view of development: The journey of separation

 Forum

Your view of development: The journey of separation

  • This post has been created in response to the massive ongoing debate about OO performance, and some of the discussions within regarding M-S-E and PABLO etc etc.

    I'm trying to throw away 20 years of thinking, some old some new. I want to pretend that I am a brand new ABL developer (mysteriously however, I know the language inside out, ABL, OO and .net) , and am asking for help and advice on this theoretical journey. I also going to be playing devil's advocate a lot of the time, but not actually say when Hopefully this will lead to a reasoned debate where new developers can understand the reasons for doing what we are doing, not just blindly following the latest trend of the year.

    I have a requirement for a report that needs to run on a  scheduled basis, and ad-hoc as and when needed. This report has 2 options

    1) Customer group to use. Customer Group is a table containing  a GUID and name. The CustomerGroupLink table holds the group guid and customer guid, which leads to the customer table

    2) Date range to use (a char variable that is used to calculate a start / end date range. This could be "Yesterday" "Last week" "Last Quarter" etc

    Basically the report is meant to look through all sales of items to these customers within the date range, and aggregate the figures together , summarising by customer and then totalling at the customer group.

    Old way

    ======

    15 years ago, we would create a window/dialog, put in a browser with a crud toolbar, and add a "run" button. The report itself would be an internal procedure, using the screen-values of the variables, or *gasp* parameters (v6, anyone ? :).

    10 years ago, we would split the report from the UI, so that the report could be run without the UI

    5 years ago, we would separate out the DB from the UI. and use temp-tables on the UI side, passing the TT back and forth

    0 years ago I am really confused

    We seem to be heading down the "let's create as many separate objects  as possible in order to confuse the hell out of the elder generation, and make it impossible for the new to get to grips"

    From what I can gather, we need UI, BL, and data layers. Oh, and all sorts of objects to deal with these layers. So, 15 years ago we had a single program, now we need at least 5 or 6

    #1) do I create separate BL modules for the Group, link and customer tables ?

    #2) do I then need to create separate modules to read this data and present it to the UI

    #3) do I then need to pass this data onto the UI, regardless of UI

    #4) when trying to run this report from a scheduler, do I need to create an additional helper, as you cannot run objects directly from startup

    #5) IOW, how would you approach this ?

    let's remember - trying to do a simple thing here. Not send a manned spacecraft  to mars.

    Julian

  • jmls wrote:

    15 years ago, we would create a window/dialog, put in a browser with a crud toolbar, and add a "run" button. The report itself would be an internal procedure, using the screen-values of the variables, or *gasp* parameters (v6, anyone ? :).

    10 years ago, we would split the report from the UI, so that the report could be run without the UI

    5 years ago, we would separate out the DB from the UI. and use temp-tables on the UI side, passing the TT back and forth

    0 years ago I am really confused

    We seem to be heading down the "let's create as many separate objects  as possible in order to confuse the hell out of the elder generation, and make it impossible for the new to get to grips"

    From what I can gather, we need UI, BL, and data layers. Oh, and all sorts of objects to deal with these layers. So, 15 years ago we had a single program, now we need at least 5 or 6

    Can I add an "amen"? I can understand the theoretical basis for object-izing every period, quote, and exclamation mark. I'm wondering what going to that level of detail buys us, particularly from a performance, developer productivity, and ongoing maintenance standpoint.

  • Since you have so much spare time on your hands perhaps you could code up examples of your 15, 10 and 5 years ago approaches? 

    Then we could let the advocates of POOP try to convince us that their various approaches bring some sort of benefit to the table.

    --
    Tom Bascom
    tom@wss.com

  • advocates of POOP

    Progress object oriented programming?

  • Heh, who said I had too much time ? Part of this was actually the lack

    of time - it would take me a couple of minutes to know up a "15 years

    ago" screen, and a few hours to do the "0 years ago" plumbing, and I'm

    trying to get to grips on what it actually saves me.

    Julian

  • --
    Tom Bascom
    tom@wss.com

  • Exactly.  Over in that other thread there is lots of noise about "show me the code" (but precious little actual code).  As you just said an old-style example could be put together in short order.  So since you have specified a nice set of objectives and you're interested in how to bridge the gap (and whether or not it is worth it) it only seems fair to establish the baseline by showing your code first.  Don't worry we will be laughing with you, not at you

    --
    Tom Bascom
    tom@wss.com

  • GUID, SchmooID.  We didn't have no fancy data types and functions back in the day; we made do with integers and liked it!

    --
    Tom Bascom
    tom@wss.com

  • 15 years ago, we would create a window/dialog, put in a browser with a crud toolbar, and add a "run" button. The report itself would be an internal procedure, using the screen-values of the variables, or *gasp* parameters (v6, anyone ? :).

    10 years ago, we would split the report from the UI, so that the report could be run without the UI

    5 years ago, we would separate out the DB from the UI. and use temp-tables on the UI side, passing the TT back and forth


    Is AppServer somewhere in your equation?

  • yeah, the 10 year one - the report can be run on appserver , generate

    report on appserver.

    5 year one , report can be run on appserver , pass report back to

    client as temp-table

  • OK IMHO it would indeed be a very interesting excercise to see at least the 5 year old code.

  • Ok, added the 15 and 10 year things. This is where it's got interesting - I'm contemplating what I need to do in order to write the 5 year thing, and now I've got to really sit down and write a *lot* more code . And that's before I start on the 0 year stuff.

    10YearReport.w.zip

    10YearReportProc.p.zip

    10YearUpdateReport.w.zip

    15YearReport.w.zip

    15YearUpdateReport.w.zip

    report.df.zip

    Bear in mind that the 10year stuff could be altered for the appserver easily enough.

    This is run on the sports database, with the reports table added in

  • Julian, interesting that you should select an example which is basically a static image on the data aka a report as you called it, although one of the views you specify is a browser.  I say "interesting" becuase there are some significant ways in which this type of example is unlikely to illustrate the issues which you are querying.

    First, as an aside, I should note that I have long been a fan of using third party reporting tools.  So, if one goes that route, the ABL involved becomes pretty minimal.  One needs a client-side screen for collecting the parameters, a server-side service for submitting the report for execution, and possibly a client-side function to obtain the results and display them on the client.  That ends up being two client-side pieces and a server-side service which is in that infrastructure box along the side of the BL and DL layers.  The only other server-side piece, if anything, is a little snippet of code in the interface layer for making the connections to the service.  BTW, the compelling reason for my thinking in terms of third party tools like Actuate is that the control over the appearance of the output is extremely good and in the case of Actuate specifically, the added value of the repository is considerable.

    But, let's suppose that one is going to do this entirely in the ABL.  Again, it is in some ways not very illustrative of OERA layering since, as you have described it, there isn't really any server-side BL, unless one is formatting the data for printing instead of merely passing it along to the client.  Really, all you need is a DL component to fetch the data and aggegate a result table .... just exactly what you would have done if you hadn't been thinking of any layering whatsoever.  So, you end up with the same parameter screen in the client which talks to an interface component on the server which creates a BL component which asks a DL component for the data.  Then the BL component either passes the data back to the interface or formats the report.  Back at the client, the presentation component becomes a little more complex because one has a client-side DL to receive the data from the server, possibly a BL component to handle format, scrolling, whatever, and a presentation componet to actually draw things on the screen.  That last bit is MVC or MVP structured.

    And, you can do it with or without OO.

    Yes, that is more components that the legacy operation of having client-code reading the DB, but once you make the move to AppServer the overall complexity of the code doesn't change much and it is all running in the same location.  One breaks the same code up into smaller pieces to simplify maintenance and promote possible reuse, e.g., the DL component might be capable of serving a number of reports and the interface components also might be made general purpose.

    One might wonder why the question is on the GUI for .NET forum since it is basically an architecture question.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • tamhas wrote:

    Julian, interesting that you should select an example which is basically a static image on the data aka a report as you called it, although one of the views you specify is a browser.  I say "interesting" becuase there are some significant ways in which this type of example is unlikely to illustrate the issues which you are querying.

    First point was that this is in itself a simplistic view - in order to minimise the "guff" that could obscure. So, the "browser" is to select the type of report (select report parameters) which is read from the db. What would I need here for OERA style compliance ?

    First, as an aside, I should note that I have long been a fan of using third party reporting tools.

    Again true. But, again, this is the most simplistic way of showing what I was trying to get at. If I am looping through order lines to count them, or performing some business logic on the order lines (for a stupid example, every 3rd orderline is not counted) the principle is the same. Where does the BL sit ? In it's own layer ?

    But, let's suppose that one is going to do this entirely in the ABL.  Again, it is in some ways not very illustrative of OERA layering since, as you have described it, there isn't really any server-side BL, unless one is formatting the data for printing instead of merely passing it along to the client.  Really, all you need is a DL component to fetch the data and aggegate a result table .... just exactly what you would have done if you hadn't been thinking of any layering whatsoever.  So, you end up with the same parameter screen in the client which talks to an interface component on the server which creates a BL component which asks a DL component for the data.  Then the BL component either passes the data back to the interface or formats the report.  Back at the client, the presentation component becomes a little more complex because one has a client-side DL to receive the data from the server, possibly a BL component to handle format, scrolling, whatever, and a presentation componet to actually draw things on the screen.  That last bit is MVC or MVP structured.

    There is almost as much words in the above sentence as there is code in the entire 10year program example

    What I would like to see from the OERA /BL / DL / MVC / MVP adovcates is (assuming that there is some business logic in 10YearReportProc.p) is what you would need to do in order to create the same results using OERA and BL and DL etc etc

    One might wonder why the question is on the GUI for .NET forum since it is basically an architecture question.

    It's in .Net because that's where I started thinking about this excercise - I want a .net, RIA and ABL frontend. What I was debating was the ROI on doing the OERA thing, as my time is precious

  • OK, as the person responsible for the OERA, and therefore it's current custodian, let me clarify at least one point.

    At the end of the day a layered architecture is about separation of concern and about choosing the right level separation for your individual circumstance.  So, within that framework, is it legitimate to simply separate the UI from the business logic so you can at least support your .NET, RIA...clients, absolutely.  Are there situations & circumstances where it makes no logical sense to separate the business logic down into distinct BL & DL layers, of course, just as there are situations where it makes sense to do the separation.  There seems to be a real hang up or perception that if I'm not doing all the level of separation as shown in the OERA that people are some how performing a heinous crime!  That's not the case, and certainly never a position that we have advocated.  It's all about choice and consequence, and the aim of the OERA is to present a set of choices, and yes there are consequences to those choices, but after reading the OERA materials you're hopefully in a more informed to position to make the best choice for you.

    OK, so maybe that was also more words that it takes to code the solution, so I'll get off my soap box now