Lately I have been getting a lot of questions about which technology should be used for the data model of an ADF application. So that’s when I decided to outline some of the characteristics of 2 widely used frameworks and provide you with some pointer for choosing one of the two.
Now first off, from my and “Oracle’s” standpoint there is no preferred way, hence the JDeveloper slogan “Productivity with choice”. The way to go always depends heavily on the business you are modeling in your application.
For all intents and purposes we will be assuming you need to access a database for use in your application and you need to decide what technology to use. I will also assume you have a clue as to what BC4J and EJB3 are, because if you don’t this post is definitely not for you.
You choice might be influenced by the following factors:
1. Datamodel of the database itself
This is highly relevant. If there is no database in existence and you can design and implement one for your own you are in luck, but mostly one has to work with an existing database one isn’t allowed to customize. Now imagine you have to display customer information in an ADF table view but the information you need is spread out over multiple database tables. In this case it is easiest to create an EJB Service that combines these tables for you so in your view layer you can simply drag and drop the control. (In BC4J you can achieve the same by creating a view based on multiple entities, but an EJB service give’s you all the control you want) On a related note it is my belief it is always better to do complex (business) logic in the service as opposed to in the view layer. This makes both the view and service more maintainable and less error-prone. (because your view is much cleaner and does only view related things)
2. Primary Keys
A very important point to take in to account is the existence of primary keys on tables. In the ideal world all tables in a database have at least one primary key to act as a unique identifier. ADF need primary keys to display the right results. In cases where you do not have primary keys on tables it is recommended to use BC4J as you get the option to use the rownum as a primary key. In the case of EJB3 you can use metadata to specify a column as the primary key even though it isn’t in real life. ADF will accept this but when it finds the same key in a table at run time it will think both of the rows are the same. Now it will simply display the second one from cache. This gives some weird results I can tell you.
3. Choice of IDE
BC4J is tightly integrated with JDeveloper as opposed to EJB3 with which you can use any environment you like. Part of the speed of developing ADF applications is this tight coupling of BC4J with JDeveloper because it has all sorts of tools and wizards that will help you creating and maintaining a BC4J service layer. So the choice here is clear. Use JDeveloper if you want to use BC4J. If you do not have a choice of IDE and the choice is not JDeveloper, then go the EJB3 way!
4. Application Logic
BC4J is more focused on application and business logic, as opposed to EJB3 which gives you a great way to access your database in an object-relational way. Both frameworks will look at the entities to provide basic validations but business components allows you to store much more validations and relations with other tables in the service layer. This enables the ADF view layer to automatically (almost magically) display lists of values, complex validations and filters by simply dragging and dropping the data source on the screen. For example for the fictional column “membertype” which can be “Employee, Management or Board Member”. This will be displayed as a list to choose from. Also a criteria that an employee cannot earn more than a certain amount of money per year can be enforced in the BC4J layer. Please note that you will have to specify these criteria yourself in the BC4J model. In the case of EJB3 you would have to add the list of values yourself after you’ve added the table. The same goes for this validation. (again think of keeping your view layer clean and trying to realize this functionality in the service layer)
So a good question you need to ask yourself is: Do I have to enforce a lot of complex business logic in my application? If so, you might be better off using BC4J.
5. Existing Services and productivity
And last but not least, it might be possible that a lot of the desired functionality already is available in existing EJB3 services. If the entire company runs on EJB3 services and they provide you with all that you need it would be madness to deviate from this technology for the sake continuity, maintainability and cost-effectiveness.
Just make sure to communicate the pro’s and con’s of using either service in terms of development time. Because in my opinion lots of the productivity of ADF comes from the maturity and completeness of the services you are using. So think hard about the services you need and whether they provide all the data you want to display in your views. If not, extend them beforehand or combine these with some BC4J services because they are not mutually exclusive. Whether you choose to combine these 2 technologies is another discussion entirely.
So now you have some pointers for helping you choose between these two technologies. As said before it mostly depends on the existing infrastructure and business. It therefore is wise to sit down with the parties involved and use the information you gained from them to make a choice.
I hope this post will be of some help to you all. Feel free to add your own thoughts below.
After all not everything is written in stone!