Application Module Impl vs Backing Bean

[srinidhi k]

Hi Experts,

We have started to build an adf application which is divided into 6 modules.

Now, all of them have different model projects ( apart from the common model ), different view controller projs.  and the model app. is taken as a shared library

into the view controller .

We are here dealing with total about 600 tables in the DB.

Now , for the DML operations, we realize that the best practice is to handle it in VO impl or the AM Impl class to preserve the MVC Structure.

But an argument can go in a way that with this the AM impl will be very huge and thus only those methods which could be reusable can be put into the AM impl and the rest of smaller DML

operations, which are specific to the page can be put in the backing bean itself. ( like changing the value of one of the attribute in a vo on submit of the page ) .

ADF allows us to access the vo using the iterator name in the backing bean and perform commit operations on it.

So, I would like to know

1. Since we are into a huge application, does handling of every DML operation in the AM Impl will prove to hit the performance even with AM pooling ?

2. Is it strictly advised to perform any DML operation in the AM Impl or VO Impl and then accessing them through client interface in the bean.

3. If the above point is true, then why adf allows to access vo's in the backing bean . There should be some reason for it. would like to know in which cases this will be helpful.

Thanks and Regards,
Srinidhi

[Florin Marcus]

Hi Srinidhi,

First of all, splitting the business  of  600 tables to only 6 workspaces might end up with many files per workspace. This might not be a problem at runtime, but it would make JDeveloper look sluggish at development time.

But I totally agree: encapsulating all the business methods inside application modules is something to be worried about, when building large ADF applications. But again, this is rather a developing-time problem, than a runtime one: imagine the amount of merging required if your entire team work on the same file. 

For this reason, we tend to create custom methods in View Object Impls, instead of using application module classes.

I wouldn't say that using custom methods on BC level is strictly required, but definitely it has it's advantages in terms of productivity, since a developer can test the business logic through BC Tester or JUnit tests without deploying on WLS. Our experience showed that more complex the logic,t he harder it is to maintain managed beans holding business logic.

I believe this is one of the most common misunderstandings  in  ADF design, when developing applications using ADF Faces and ADF BC.

As for the reason ADF allows access of VO's from the backing bean:  ADF is a framework exposing a set of API's that should welcome various use cases. We should not confuse a tutorial for a best-practice in building production ADF applications.

Hope this helps,

Florin Marcus

Red Samurai Consulting

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
 
---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Chris Muir]

As extension to Florin's well thought out answers, 

Traditionally the argument for doing all the business logic in the model layer has always been with the implied threat "if you ever change your UI technology implementation you'll regret doing such logic in managed beans because you'll need to rewrite it". However the complete JDev & ADF tech set was changing so much (think v1 to v2 to .... v11) that I suspect most customers went for a complete rewrite (if at all), so this was really a hollow threat.

With JDev 10g, & much much more so in 11g we see the tech set has settled down/massively matured such that what you write in ADF BC in 11g will likely survive for versions to come. Indeed 12c could have been arguably called 11gR3.

So now we have that framework stability, is the MVC argument worth any more merit now?

Within the 11g timeframe and with more momentum in the 12c timeframe, exposing ADF BC as SOAP based web services, and sometime in the future REST based web services, will gain more momentum/importance. Indeed I'm frequently asked questions by ADF Mobile programmers how can we integrate our traditional ADF BC business logic in our server apps into our ADF Mobile apps without having to rewrite everything from scratch? Answer: ADF BC web services.

As such if you now code logic into the managed bean/UI layer of your server based ADF application, in the future when you choose to integrate a mobile solution (be it with ADF Mobile or some other tech) you may come to regret that you've placed business logic in the wrong place. While there are certainly arguments of the suitability (or not) of ADF BC exposed as web services, we can see from this discussion on mobile that MVC has proven its worth again. 5yrs or less ago we probably wouldn't have predicted this, but integrating mobile (as separate to a different UI technology) is another proving point to the while MVC argument.

Putting aside the above discussion, if you implement a grey rule regarding where business logic goes, rather than the much clearer (though not perfect) MVC guidelines, as an ex team leader, (to quib an Australianism), how on Earth are you going to enforce this mess? Your junior programmers are always going to think they know best and push the boundaries of what should go where, it's as good as no rule whatsoever.  Before you know it you'll have managed beans opening their own JDBC connections, your DB connections per user session spiralling out of control & as result a poorly scalable app, Java programmers implementing stuff ADF BC already does because they're ignorant of ADF BC's functionality & now have an excuse not to use it, and yet another rant "ADF failed us" when indeed you haven't implemented an ADF MVC application, you've gone some Java/JSF free for all root. 

My money is on following the MVC guidelines for successful ADF projects. If you don't want to do stuff the way ADF does it, don't use ADF.

CM.