To Extend or Not To Extend Base Classes?

This is one of many follow-up to my previous post: Planning an Enterprise Scale ADF Implementation?

Should you extend your base classes in your BC Model project? It's up to you if you think you'll need to. Do you think you'll need to change a built-in feature to behave differently or to add a new feature? Do they need to be used by all of your applications? To do so requires that you do it prior to generating any business components in your project. The most common components extended are:

• Entity Definition
• View Object
• View Row
• Application Module
• Database Transaction Factory
• Database Transaction

By extending these classes you can override logging methods to provide your own unique logging to your applications. Or you can override transactional methods like the doDML() methods handling the transactional commit operation.

 If you think you will use shared business components then you need to use generic extended interfaces. I would go ahead and set these up and get use to using the extended classes. It will give you a way to provide a common interface to all your business components. Any exposed custom method in any of your generic extended base classes can be used in any other business component class in the application.

So there are a lot of benefits to using extended base classes. It's just up to you and your development team to use it the right way.

Planning an Enterprise Scale ADF Implementation?

There are tons of resources out there that follow the same standard MVC architecture by using the "Fusion Middleware Application" template provided by JDeveloper 11.x. But is this sufficient for a large scale enterprise application or portal? No ... I don't think so. I highly recommend that you structure the overall project by using workspaces, projects, and libraries. By organizing application specific artifacts (BC Model, taskflows, templates, java utilities, project properties) into shared libraries will increase productivity amongst your team and provide the modularity your project needs to be successful today and in the future when you start enhancing the applications with new developers rolling on.

I typically structure my applications to use a SharedBC and SharedViewController project. I create a deployment profile for each and deploy them on a network shared folder as an "ADF Library JAR File."

Now any developer can create a "File System" resource in their Resource Palette.

After that you should be able to see your deployed libraries when you expand the resource.

If you want you could also set the dependency on the shared VC from the build output of the shared BC and deploy just one ADF Shared Lib. So it just depends on how you modular you want your components to be. Now the shared code is packaged and ready to be consumed by other applications in your enterprise. This will allow your development team to be more productive and allow them to only change code in fewer places. I suggest you start on a small scale to make sure everyone understands the capabilities and the benefits of this before things get a little hairy. I would put together a few POCs using this method and do a write up explaining why and how to use this.

In future posts I'll go into setting up extended base classes in your model application, ADF logging, controller utility examples, binding examples, and some tips and tricks in Skinning/Templating.