Disclaimer: The words that follow are my own and are not representative of Oracle nor it’s subsidiaries. While I work for one of the leaders in our industry in technology and business I do not write this blog with the intention of representing them. These thoughts are purely my own and as such I take full responsibility for them.
I have been really struggling with coming up with a post about ADF since I started working in the Fusion Apps development group at Oracle in June of last year. Firstly, I didn’t want to start posting on how to solve common problems, as there are a lot of blogs out there that already do this. A simple google search for whatever problem you are having will reveal this. Many answers can also be found on YouTube with step by step instructions. Secondly I didn’t want to sound like an official Oracle blogger giving insight into the direction of the framework – my role at Oracle does not afford me with that ability. Lastly and probably the most important, I needed to be careful in what I posted as to not give away any trade secrets, specifically how we handle things in Fusion.
So what I decided to do is compare an industry wide common stack that I have used; Hibernate + Spring + JQuery to Oracle’s ADF framework. This will allow me to steer clear of specifically addressing any Fusion development and allow me to refresh my Hibernate and Spring experience.
So without further ado let me start by making some observations.
Am I A Lazy Programmer? Oh Hell Yeah!!!
First of all I like easy. With all due respect to Staples, their easy button commercials have nothing to do with buying paper. It’s me in a nutshell. I really should have a shirt with an easy button on it, stickers on my car, and an easy button on my desk to represent who I am. I cannot stand to work with anything that has been made overly complicated just to solve problems that rarely come up, while making solving real world every day problems difficult. I do not like API’s with optional parameters. I do not like using a bunch of config files just to provide the ability to customize an application that will be customized in only rare circumstances. If it takes me more than 15 minutes to figure out what I need to pass to your interface to make it do something, your interface is crap.
Secondly I really like writing test code. I spent 13 years traveling the country trying to implement code that wasn’t well tested. I learned through this firing squad indoctrination to poor coding practices how utterly important it is that code does not fail when it’s being rolled through the staging process. Once code is in production errors become incredibly difficult to debug, and by design incredibly expensive to fix. You do not want your customers dealing with this problem or your reputation will suffer.
Thirdly and this is really an extension of my first point. I like code that is small. There is never a need to have methods with 1k lines of logic in them. That’s a different kind of lazy. That’s the kind of lazy that says “I want to justify my job by making this so difficult to understand only a Senior level engineer could maintain this.” Well I want to write code that is so easily understood that a Junior level programmer can pick up what I am doing. If you don’t agree with this, read the book Clean Code – A Handbook of Agile Software Craftsmanship by Robert Martin.
Lastly I am an examples guy. Documentation if it’s crystal clear and straight forward is helpful. However in most instances it’s written by a developer for a developer who has intimate knowledge of the subject at hand and and it’s usually out of date. Maybe this stems from how I learn – by doing rather than by just reading or listening. How I came to learn this way I will never know, but if I don’t see examples and only see poorly written documentation I will not be recommending your framework to my colleagues.
So anything I say from this point forward should take these statements into account.
My Impressions of Hibernate+Spring+JQuery and ADF
Spring is easy to learn and incorporates two very popular design patterns right out of the box. IOC (aka dependency injection) and the MVC pattern. Lately I have been asking all the candidates I interview about the MVC pattern and I am often utterly blown away by how little most know about this. Most candidates get confused about what a controller is, and where the business logic lies. But, even the ones that seemingly know the pattern don’t know why a project team would choose to use it. Very few(like 5%) knows what IOC is or if it’s useful in testing. I am not sure why this is, but it seems to stem from the fact that very few people test their code.
Spring makes Dependency Injection incredibly easy, thus giving the programmer the ability to mock objects and test logic flows.
Also a simple google search will return hundreds of thousands of hits with real implementation examples on how to deal with particular issues. So that is a huge plus for Spring + Hibernate + JQuery.
But ultimately using 3 different frameworks has it’s challenges too.
It is easy to create an ADF application without knowing ADF at all. Yes this is the case and as a matter of self preservation, I can’t say that I am overly supportive of that. There are a multitude of demos on the Oracle ADF site that detail exactly how you can create pretty complicated web apps rather quickly These examples provide a great way to learn how to implement the different concepts in ADF, though they don’t teach you a great deal about why you would make certain design decisions.
ADF is very much based on the MVC pattern, as well as a few other important ones such as the Business Delegate, the DAO pattern, and of course the Singleton pattern. Many others are used but these are the most frequently interacted with.
With that said, ADF is not easy to learn. Sure you can turn around a few apps really easily but beyond that when you start asking all the how to, or better yet, “how best to” questions, this is where it can get fairly complicated. On this I am still withholding judgement because I am inclined to understand that its intention is the whole web application stack.
One of the main differences between ADF and Spring is that Spring is an application framework, but it’s not an ORM or a view component library. You often have to implement much of the ajax code between the user interface and the backend with different helper libraries. ADF as a single framework, also encompasses the ORM layer and the Component View layer. This gives the programmer the freedom to not have to worry about so much plumbing. In ADF I never have to create Entity Objects, then wire them in a config file. Creating specialized views of data, so as not to expose everything within a table or even an entity object to a consumer of my model objects is also extremely easy in ADF. This is why I have decided to not just include Spring in my analysis of the two frameworks but instead also include Hibernate and JQuery.
So stay tuned while I dive deep into these two application stacks and compare many of the pluses and the minuses I have found while using them.
