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

2

 

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.

 

Share.

About Author

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director for Fusion Middleware. Consultant, trainer and instructor on diverse areas including Oracle Database (SQL & PLSQL), Service Oriented Architecture, BPM, ADF, Java in various shapes and forms and many other things. Author of the Oracle Press book: Oracle SOA Suite 11g Handbook. Frequent presenter on conferences such as JavaOne, Oracle OpenWorld, ODTUG Kaleidoscope, Devoxx and OBUG. Presenter for Oracle University Celebrity specials.

2 Comments

  1. JSR-227 – is that thing still out there? Looks to me that Oracle has failed miserably getting this specification accepted – see also: http://jcp.org/en/jsr/results?id=2045
    Interestingly enough also BEA voted against this specification. So basically imo there will never be acceptance for 227. Look for http://jcp.org/en/jsr/results?id=3865 for a more viable alternative already receiving YES votes across the board. Since JSR-227 is the corner stone of Oracle’s ADF, and because their effort in getting acceptance for this spec has failed, ADF will always have the smell of being to much a proprietary tool.

  2. Jan Vervecken on

    hi Lucas

    Maybe Oracle can make your ideas fit in with JSR-227.

    regards
    Jan Vervecken