Reusing and Extending ADF BC Entities from Common Model

This post is about ADF architecture and better application structuring with EO reuse from common model. I describe how to implement additional requirements to common model in extended ADF BC Entities. Great power of ADF framework - reusability. You should reuse as much as possible, this would simplify maintenance and future development of your application. I will be talking about ADF BC Entity Objects (EOs) reuse in this post. I would recommend to keep EOs in common model project and reuse them across the application. Fair requirement would be to have slightly different EO for specific use case - instead of creating new EO for the same DB table, we could extend original EO and implement specific changes. As for example, we may have different set of business rules, different doDML logic.

Sample application developed for this post includes Common Model library and Main application - eoreuse.zip. Common model library is based on Employees and Jobs EOs, associations and EO implementation generic class:

Employees EO from common model library implements business rule for Hire Date attribute - date must be today or in the past. The idea is to show that business rules from common EO will be inherited by extended EO as well:

Generic EO implementation class overrides doDML method, I do this to show the sequence of doDML calls from extended EO:

doDML method from Employees EO is overriden in the same way as in generic EO class:

We switch now to the main application - where common model library is imported successfully. Employees and Jobs EO's are available in the main application:

Here we can create new EO - extending Employees EO from common model:

In order to be able to change properties of specific attribute, we need to override it. Salary attribute is overriden and I have defined additional business rule - salary value check:

As we have extended main Employees EO, we need to define discriminator attribute. This is a key part, otherwise main Employees EO will stop working. As there is no really discriminator attribute in Employees, I'm going to create new transient attribute with default value 0:

Discriminator attribute is included into extended Employees EO, this attribute is set to be hidden - it will be never displayed on UI:

I have defined one additional association in main application - between Employees extended and Jobs EOs. We can assume, this would be required by specific use case:

Employees VO is created inside main application, calculated discriminator attribute is set to be populated from query expression - always returning 0:

This is how value is returned for discriminator attribute from SQL query:

The same value 0 is set for discriminator in VO based on extended Employees EO, it is calculated from SQL query expression:

Query for this VO is the same as for VO based on main Employees EO:

There are two View Links defined for Employees VO based on extended EO. First View Link is reusing Association from common model between employee and manager, this works perfectly for extended EO. Extended EO can reuse Association defined for parent EO:

Second View Link is using Association defined in main application - one between extended Employees EO and Jobs from common model:

Here you can see final ADF BC Data Model structure exposed. Master-Detail relationship between Jobs and Employees from common model, Master-Detail relationship between Employees VO based on extended EO and Jobs from common model, plus employee - manager relationship reusing Association from common model:

Sample application provides ADF UI implementation, where two tabs are given. First tab displays Employees VO structure based on main Employees EO. Second tab displays Employees VO structure based on extended Employees EO.

In the first tab - in the Employees list based on selected Job, business rule common model for Hire Date is working:

In the second tab, Hire Date business rule is working:

Plus additional business rule for Salary attribute, from extended EO is working as well:

Same rule is not reproduced for Employees data in VO based on main EO - as expected:

Make sure to enable ADF logger for application classes, we should check the sequence of doDML calls:

In the case of VO based on main Employees EO - firstly doDML from Employees EO is called and then from generic Entity Impl class:

Now, if you don't want to call doDML from main Employees EO, when calling doDML for extended Employees EO - make sure to change extending class:

As expected - doDML from extended EO is called and then doDML from generic Entity Impl class: