ADF 11g Project Structure – Part 3: Independent Apps

Update 7/30/2013 – See my updated and final structure here:

https://wesfang.wordpress.com/2013/07/30/mskcc-adf-11g-application-project-structure/

 

Notes:

*numbers are placeholder for actual module name

Deployed as mskcc-app*.jar

Jar Dependency:

Model project uses mskcc- common-model.jar

ViewController uses mskcc-common-viewcontroller.jar

Question:

After speaking with someone from the Oracle fusion apps team, it sounds some of the fusion app is further split up to FusionModelApp and FusionViewControllerApp.  I’m still not sure why.

Advertisements

About wesfang

www.linkedin.com/in/wesfang/ https://twitter.com/wesleyfang
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to ADF 11g Project Structure – Part 3: Independent Apps

  1. Anand says:

    Wes,
    This is a great post, one that has been very helpful for our project. I have one question though about keeping entities in a separate package. Why is that? I am still of the opinion that Entity should go in the respective module packages, so that if the developer changes it, he will not forget to make changes to the other layers if required. Else many time we get run time errors where VO and EO do not match.

    • wesfang says:

      Hi, I’m glad you found this post useful. I am still working on an actual implementation of a prototype with my team. One thing I will be removing the use of RootAMs and design time nesting of child AMs. The other issue has also been raised with our developers which is the same question you are asking. Since entities are logical representation tables, there really should not be more than one in the entire system which represents the underlying table. The problem we ran into frequent back and forth modification between your ChildApps and the CommonModel. Instead, moving forward we will be carefully creating EOs in both CommonModel project and also in the ChildAppModel projects. Only EOs that are deemed to be shared by other apps will reside in the CommonModel entity package while business specific EOs will reside in their own module package. Now one problem I can forsee with this is a EO is defined in a ChildAppModel1 and months later, another ChildAppModel2 also requires that EO, at which point it might be easier to have a duplicate definition vs adding the dependency between the two ChildApps. OR attempt to refactor the EO from the ChildAppModel1 into the CommonModel. In short, your approach is also what I will do as well but also define EOs that are known to be shared across all ChildApps in the CommonModel.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s