Skip to main content

Self Building Value Objects: A pluggable alternative to the Adapters/DAO/DVO pattern

Let's face it, change is the way of life. Inevitably, change is the way of software too.
In case of enterprise applications change is continuous. This comes in the form of new business requirements involving complex logic and changes to the interfacing systems.

Logic can change on its own and usually does not cause changes to interfacing systems.
But the other way round is a completely different story.

It is an extremely bad practice to let interfacing systems' scheme (classes and relationships) to propagate through your application. No one does that, no one should.
We depend on the use of Adapters, DAO and Value Objects that carry data through our applications and let our logic run on those.

Yet, one complexity lingers, how to safely and easily move from one interface to an alternate one. Say today our application uses a traditional relational database like Oracle and we want to replace it with a NoSQL database like MongoDB or Riak or Cassandra?

Changes to value objects is costly. An easy option is to build new adapter/DAO while reusing the value objects. This provides easy migration from one interface to another, but still causes the central business logic to change, where it needs to call a different set of adapters or DAO classes to build the VO.

The easy way out is, building your application using self building value objects. What that means is the value objects, know how to build themselves. The adapters/DAO shall be implemented as Strategies and the "building" of the VO, shall be a behavior of the VO, which is implemented by the "pluggable strategy". Furthermore, the choice of strategy can be delegated to a factory and thus made configurable.



The application logic instantiates DataBaseVO while passing the required instance of the DatabaseDAOStrategy. The identification of required instance can be done using a factory.
Once the VO is instantiated, the buildMe method shall be invoked which calls the buildDatabaseVO method on the strategy instance.

This can further be extended, as needed to invoke back ends asynchronously. The buildMe method can be replaced by implementation of run method, while DataBaseVO implements Runnable (or extends Thread). A flag determines whether the object is built or not. The central application logic can invoke retrieveData method to get completely built instance of the DataBaseVO.


So try this out the next time.

Comments

Post a Comment

Popular posts from this blog

Catch hold of that Exception and hide that stacktrace!!!

E xceptions happen!!! Rules are to be followed, too. Time and again, Java developers are told the golden rule to catch specific exceptions and not to catch the generic Exception. The thought process behind that is, applications should not catch runtime exceptions. This is apt as runtime exceptions are an indicator of "bugs" in the code. However, blindly following rules, as always, can have unexpected consequences. If you are developing services that are to be exposed over the wire, it is always a good idea to break this rule and "catch that Exception". Instead, follow the below principles: Service methods should implement a generic Exception block, along with catching declared exceptions, thrown from inner layers of the code.  If needed, the service can throw another exception back to the client. What's important is that we create a new Exception instance to be thrown, along with relevant message for the client. The service can log stacktrace for the E...
Post a Comment
Read more

Using JNDI managed JMS objects with Apache CAMEL

Apache CAMEL uses Spring JMS to work with JMS Queues or Topics. Evidently, we will need Spring to configure and use JMS capabilities provided by CAMEL. Details about how to implement JMS based routes using Apache CAMEL can be found in the CAMEL documentation. However, the documentation leaves a lot to be figured out. In a typical Java EE container, it is usually a good idea to abstract the underlying JMS resources by using JNDI. We can use the below configuration to achieve that. This configuration is tested in Websphere environment, but should work in any JEE container. Create a JMS queue connection factory in the JNDI registry. CAMEL configuration will be able to use only one queue connection factory, even if we have more than one. Create one or more JMS queue or topics, in the JNDI registry, as required. The above two steps are related to generic JNDI configuration for JMS resources. Now we come to the setup required for making these JMS resources work with CAMEL rout...
Post a Comment
Read more

Cassandra data modelling: Redundant data, a tough decision

The biggest challenge around building an efficient data model for Cassandra is data redundancy. Though the basic rules for data modelling with Cassandra, mention the usual RDBMS modelling goals, as non goals for Cassandra (Refer:  Basic rules for C* data modelling ), it builds upon assumptions that clusters are built on commodity hardware, storage is cheap, and as data needs increase more nodes can be added to the cluster incurring very low cost. But in real life we are faced with technical as well as non technical problems. a. Keeping multiple column families in sync can be a major overhead, if the same data is spread across them. What if writes to some CF succeed and some fail? How long and how much will we retry? b. Horizontal scalability may be a truth, but think of a mundane question of where to keep all those heat producing, energy guzzling machines? So how do we model the database that does not allow joins without redundancy? The simple answer is, we do not. Wh...
Post a Comment
Read more