The rise of the ViewObject – or: isn't the ViewObject the real Data Control?

The ADF Model is positioned to decouple the Application from the implementation details of the Business Service(s) it uses. Any Business Service, be it an EJB, a POJO based JPA implementation, a WebService, a plain URL service (RESTful or otherwise), a Content Management API or an ADF Business Components Application Module, can be published as a Data Control through the ADF Model and from there be used in Data Bindings. The application deals with Data Bindings, the ADF Model layer interfaces with all different business service technologies. Sounds good. However: some business service technologies are more equal than others. Or to be more exact: one is more equal than others. ADF Business Components enjoys far more privileges in the ADF Model layer than the other persistence and implementation technologies do.

A ViewObject has many features that are leveraged by the ADF Model and play a role at run time, dramatically extending the scope of declarative development. Features such as Validators, declarative List of Values, UI Hints, associated resource bundles to name just a few all are defined at the ViewObject level (inside the persistence layer?) and have their effect in the application, either at design time or most even/also at run time.

Recently I have seen a few examples where instead of the more obvious POJO based data control, a programmatic ViewObject was used instead. With this ViewObject – really nothing but a facade for the underlying data source – could be associated many helpful declarative attributes that the normal Data Control does not provide. Some examples:

• the CSV based ViewObject example by Steve Muench – sample #132 of the Undocumented Samples
• the programmatic ViewObject based on a PL/SQL API, for example in Avrom’s The Power of Properties II: The View Object
• the AIA JDeveloper plugin that helps create ADF Faces applications on top of the AIA enterprise services: this plugin creates ViewObjects on top of these services, not WebService or POJO based Data Controls
• the static ViewObject – described by Chris Muir in his blog – which would be implemented using a POJO or even a Placeholder Data Control just as easily. However, the ViewObject has so much more to offer than PODC (plain old data controls)…

Do not get me wrong – I like the ViewObjects and much of the functionality they give me. But I have started to wonder whether we should not (instead of we perhaps you should read Oracle or more specifically the JDeveloper/ADF team) move up the ViewObject in the world or at least in the ADF Architecture and make it the DataControl. Allow all the declarative niceties currently available for the ADF BC ViewObject available for the new Data Control modeled after the ViewObject and provide adapterclasses that implement the ViewObject/new Data Control interface using either the ADF BC AppModule/NVO (New View Object) usages, POJOs, WebService etc. The New ViewObject would be the trimmed down version of the current ADF BC ViewObject which has shed a lot of its declarative truly View oriented functions and features to the new DataControl and concentrates only on the data or business side of things.

I believe that today’s ADF BC ViewObject is too much a combination of things: on the one hand a business facade on top of data – entities or read only queries – while on the other it is like the Oracle Designer Module Component – a container of UI oriented logic that provides useful defaults of declarative settings for when using the ViewObject in an application. That latter part is better off associated with the Data Control I think. It will benefit Data Controls of all technologies, not just ADF BC. And it makes a better distinction between the two roles the current ViewObject is playing, one oriented towards data and one targeted at, indeed, the View.

I wonder: how much effort would it be to wrap a POJO in a programmatic ViewObject – to an extent where that a Data Control with that ViewObject provides at least the same functionality as a POJO based DataControl. It may turn out that when using ADF Model it may be a best (? or convenient?) practice to always do that – and thereby decide to always work against ViewObject based DataControls with all conveniences that offers us.