Follow Us on Twitter

ADF 11g: BC4J or EJB3

by Marcel Maas on March 26, 2012 · 2 comments

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!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Tags: , , ,

{ 2 comments… read them below or add one }

Florin Marcus May 24, 2012 at 8:17 pm

This is an interesting subject.
Few notes on the article:

Now first off, from my and “Oracle’s” standpoint there is no preferred way, hence the JDeveloper slogan “Productivity with choice”.
There is a gap between marketing slogans and reality. There IS an preferred choice: ADF – Bindings – Bc4J. You can notice that from the latest survey on ADF Methodology Group, where BC4J is used by more than 80% of developers, while with JPA/EJB3 there are arround 10% :

An essential difference between those two approaches is the stateful vs stateless programming. A J2EE expert, starting with BC4J , always used to do stateless programming on Business Layer, will require a mindset change.

Bottom line, ADF + BC has a steeper learning curve, but once mastered, is more productive than ADF + EJB (see LOV integration with ADF Faces).

Florin Marcus


Eduardo Rodrigez May 27, 2012 at 4:32 am

several years now I have been developing applications in adf, and in both technologies, and it is clear that ADF are trained to work with BC4J. And that using EJB you lose many of the features that made adf interesting in the first place, nobody has mentioned, one of the main problems using ejb in adf applications (and also linked with the previous comment, the difference between stateful and stateless) when we use business compontes in a taskflow, we are likely to initiate a transaction, query and update operations and insertion even within a page and then commit or rollback. However when using EJB service, each service call begins and ends a transaction, making it nearly obsolete use in a taskflow.this makes differences even in a page developing making possible for bc4j pages to share data and simplify the developing. I suppose it’s possible to replicate this behavior (stateful ejb / bean managed transaction), but if anyone knows of a post where it explained this,and another thing to clarify is that the functionality of the data control is to separate layers and allow the data model be developed in any technology, as written in the book, but this is not so in reality, and try to changel a page from BC4J to EJB, is almost impossible without major changes.


Leave a Comment


Previous post:

Next post:

About Whitehorses
Company profile

Whitehorses website

Home page

Follow us
Blog post RSS
Comment RSS