T
Thomas Mercer-Hursh
Guest
If you reference the static method in ABL (there are no static classes, only classes with all static members), it will be instantiated and will live in memory for the duration of the session. That can be a good thing, but use with caution. I would take a look at more recent versions of ABL and PDSOE. You are missing a lot in 10.2B. The issues with the DB can be minimized by creating a data access layer to separate access to the DB from the object model of the application. You really, really, really want to get an AppServer in the mix. I would strongly advise some consulting on the architectural model before you go very far. Otherwise, you are likely to have a lot of rework and going down blind alleys. I am going to guess that the old code is old enough not to have superprocedures either. Otherwise, they are a possible model for using objects. It is a perfectly fine idea to bundle a bundle of related logic into a class, instantiate it went appropriate, and use it in the fashion you indicate (except for wanting to separate the data access part). But, apply principles of good OO design in what does and does not go into the class and pay attention to separation of concerns to minimize the dependent linkages. One good use of a static is to provide a registry by which one object can find another object without having to know very much about it. Dependency injection is another useful technique.
Continue reading...
Continue reading...