Reuse - Do you have your own subclasses of ADF BC Impl classes?

[John Flack]

What the subject says -
I've heard Steve Muench and others state as a best practice that you
should always subclass ADF BC's implementation classes even if you
don't plan at first to write any of your own code in them. The idea
is that if you later decide to add some code you have a place to put
it without major re-factoring.

Do you do this? Did it help? Did you not do this and regret it?
What sorts of things have you put in your subclasses?

[Avrom Roy-Faderman]

Hi John,

Well, as a matter of fact, I haven't been doing that in my current
applications. I've been starting out these applications with the business
components impl classes (all but EntityCache) extending enterprise-wide
framework classes.

Because of this, I haven't *usually* needed application-wide framework
classes as well. About 80% of our programmatic BC code is general enough
to go in these, and about 80% of the remainder is so specific that it
belongs in component-specific classes. That last 4% or so has been
concentrated in a small handful of applications.

There have been a few exceptions to this (where there's code that's
general enough to implement at the application level but not general
enough to implement at the enterprise level), but few enough that
refactoring hasn't, in general, been a huge problem--although note that
this is in part because our individual applications are usually small to
medium-sized (<50 BCs); it's the entire *set* of them that's big.

However, although this hasn't been much of an issue, it wouldn't hurt to
generate stubs of those classes, either, and I may start doing so. It
wouldn't hurt even to have a stub (at both the enterprise and app level)
for EntityCache, either (even though I've *never* had a reason to extend
this, for *any* client), so I might start putting that in just because,
well, you never know, right?

Best,
Avrom

--
Avrom’s Java EE and Oracle ADF Blog
http://www.avromroyfaderman.com

[Husain]

We do have a number of commonly required custom codes in base classes.
Including:
PL/SQL calling in generic way in EO - Similar to one given by Avrom.
Integrating BI Publisher reports in VO
Exception handling and throwing in AM
Logging and Audit trails in AM

I am sure we will need more things as our project continues..


Regards,
Husain

[Chris Muir]

For our current project we've done this, extending the concept a bit
further given experience from how good ol' Oracle Headstart for Forms
did it.

We've created the following layers:

a) An organisation wide custom set of ADF BC Impl's (call it common)
stored in it's own Jar
b) For each application they also get their own custom ADF BC Impl
layer which inherits from the organisation level - these are contained
within the application's ADF BC model project under their own package
c) And finally the application itself, the EOs/VOs/etc inherit from
the application level Impl's

The general intent is, the organisation wide level Impl (a) is for
common code to be shared for all applications, but not bug fixes and
workarounds. Instead the application level custom Impl's (b) are
intended for fixes to get around ADF BC framework bugs, and any common
code specific to the application at hand only. Our reasoning for not
putting bug fixes/workarounds in (a) is that eventually (hopefully?)
that the org level libraries will be used by all sorts of ADF
applications potentially running on different versions of ADF. For
some applications bug fixes/workarounds will apply, but not all, as
the bug fix may only be applicable to certain versions of ADF. As
such it is up to each application to provide a fix for the ADF
framework in it's own custom ADF BC Impl layer (b). This may result
in duplicate code across applications, but something we're willing to
wear. The alternative is keeping all applications up to date which
creates a large regression testing burden and an unwanted versioning
dependency between disparate applications. I'm vary wary of this last
scenario, I've seen organisations get into huge knots when you create
these disparate system dependencies.

In answering one of John's question, while we've set this structure up
in our 11g application, in specifically considering bug fixes/
workaround we've yet to encounter any where overriding the base
functionality is required. In my experience from a number of ADF
applications, there has only been once in a 10.1.2 application (or was
that 9.0.4, I forget?) where I made use of this structure for a bug
workaround. That may sound minimal, but I bet I would have been
screaming with the mess I would have gotten into if I hadn't had the
custom Impl's already setup.

Alternatively if we consider common code, in our current project we
have created custom passivateState and activateState functions (as per
section 39-7 of the Fusion dev guide
http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/bcstatemgmt.htm#sm0495)
at the org wide level AppModuleImpl which we can see being reused by a
number of our applications in the future.

Cheers,

CM.