Oracle ADF vs. Other Java Web Frameworks

Ben MarckTechnical TipsLeave a Comment

Oracle Fusion Middleware 11g

To extend on an earlier blog posts by a colleague here at M&S, I’m a firm believer in using different technologies in different situations. Trying to make a technology ‘work’ when another is clearly a better choice is very often a critical mistake. Reasons why these decisions get made are numerous (familiarity with a technology, existing infrastructure, etc). With that said, my own take on ADF vs. other Java web frameworks (such as Grails) is actual a lot more black & white than I thought it would be.

While ADF enables typical CRUD functionality quickly and efficiently, it’s abstraction from the actual underpinnings and code make the overall learning curve higher. Personally, I’d rather be forced to generate my own view code and Javascript, as this has become the most important part to any rich web application and understanding it’s technology at a granular level is critical. On the flip side, ADF is extremely flexible allowing you to mix and match model technologies that fit just about any business infrastructure, whereas most other frameworks typically limit your choices here. Additionally, ADF Faces provides about 100 rich, AJAX enabled UI components out of the box that have functionality such as sorting, filtering, and row selection, that you’d need to use jQuery or Prototype to handle elsewhere.

At this point, I asked myself, when would I use ADF vs. another conventional Java web framework? Here are the characteristics that I’ve come up with that best suit ADF or another Java web framework. What are your thoughts?

ADF Typical Project Characteristics

  • Enterprise
  • Internal / Intranet
  • Proprietary components ok (ADF Faces, ADF BC)
  • Style unimportant
  • Large datasets
  • Rapid development critical
  • Abstraction from underpinnings ok

Other Conventional Web Framework Project Characteristics

  • Startups / Consumer Web Apps
  • Internet
  • Style Important / particular UI requirements
  • Bulk UI changes probable
  • Open Source required
  • Dev team familiar with technology at a low level

Leave a Reply

Your email address will not be published. Required fields are marked *