Re: ADF Application Architecture Feedback

[Wes Fang]

Hi Patrick, 

You had mentioned that you would like minimal config changes in your app and the easiest way is the default generated app structure. 

When you deploy to your production environment, do you have a single ear file for your entire app workspace? 

I believe you can setup project dependency via build output as well instead of adf libs which would enable you to share btfs across viewcontroller projects. The difference being that you don't have to redeploy adflibs after changes to a dependent vc project. 

Do you foresee a lot of btf reuse across your view controller projects? 

One of the drawbacks of using adflibs or setting up dependencies across vc projects is keeping track of these dependencies. one way of dealing with them is to aggregate these btfs into a CommonVC project (difficult to do as refactoring in a java sense does not apply to jsf/pagedef/beans across projects, hence it is best to think about this before any new viewcontroller project is created). I forget the name of the emg event I attended last year but there was a talk where one of oracle's lead fusion apps developers said they draw up a giant chart of dependencies, level 0 App has no dependency, level 1 App has 1 other dependency and so on.

Single view controller is the easiest to manage and develop with. One of the annoyances is that you will likely to end up with a huge application which becomes hard to find files to work with. Our 10g application is just like this and its very annoying to work between the model and view controller layers when starting off a new subsystem creation. Also from a deployment perspective, it is an "all or nothing" event. Another potential drawback (depends on your biz requirement) is the memory footprint of the application as it is deployed with a single ear.

Our 11g app uses the Cylinder like approach and one way I with the dependency challenge is to ensure a good communication and integration method with each of our developers. It also is the best route incase we need to move to a pillar design later on. When starting a new subsystem app, careful consideration of what btfs will be created (going back to the common components decision earlier). Only when the subsystem is ready for QA does it actually get consumed as adf lib/merged to trunk and deployed to the the testing environment. A single ear is deployed to a production weblogic server .for end users. We have no requirement to selectively deploy subsystems (yet) as it's own individual ear so the biggest benefit for our system app structure is keeping apps small (number of adf faces/bc files in each app) and easy to develop/version with. 

hope that info helps,

Wes

"Since it seems that the model project is the only type of project that can be shared across projects in an application we did have to create ADF Libraries of all the view controller projects "

On Thursday, May 9, 2013 10:39:36 AM UTC-4, Patrick Harriss wrote:

After having watched the Angels in the ADF Architecture video I would like some feedback on an ADF application that we have created that doesn't quite match any of the patterns in the video. Essentially we have the following structure for our application which I think most closely resembles the Sum of the Parts pattern except that we only have a single application workspace and multiple projects inside of that workspace.

Application Workspace
      ADF Model Project - Contains the model for then entire application
      ADF Shared Project - Contains any common/shared resources (bounded taskflows, templates, java utilities, etc.)
      ADF View Controller Project 1 - bounded taskflow, functional unit of work
      ADF View Controller Project 2 - bounded taskflow, functional unit of work
      ADF View Controller Project 3 - bounded taskflow, functional unit of work
      ADF View Controller Project 4 - bounded taskflow, functional unit of work


Since it seems that the model project is the only type of project that can be shared across projects in an application we did have to create ADF Libraries of all the view controller projects so that we could reference the bounded taskflows from one view controller project inside of another view controller project. We decided to have multiple view controller projects in an effort to limit the configuration management issues that we might come across but it seems that maybe dealing with those issues and only having a single view controller project might have been better? What would be the best way to architect an application like this and limit the configuration management issues? If you are going to have multiple view controller projects does it make sense to just put those in their own application workspace?

Thanks.