The design pattern below addresses this issue to eliminate lot of boiler plate coding.
ServiceInterface – Design your service interface where it will perform some real business logic.
PassThruInterface – For lack of a better name, PassThroughInterface will contain service methods but are straight calls to dao. The approach is to separate the existing pass through methods in service layer into this PassThroughInterface.
PublishedInterface – This is the interface that would be visible to outside layer and consolidates both core ServiceInterface and PassThroughInterface. In OO terms, it extends both ServiceInterface and PassThroughInterface.
ServiceImpl – Implements only the real business methods where it does much more than calling dao methods.
DaoImpl – Implements both DaoInterface and PassThruInterface methods. From the coding perspective, there is no change as it would have done the same thing anyway in classic service -> dao approach.
ServiceRouter – This is the heart of the logic that routes method invocations with the help of dynamic proxy. As you can see, it is a specialized implementation of Spring’s FactoryBean interface and has references to both service and dao implementation classes. So when configured as a Spring bean, it returns a proxy instance of the PublishedInterface. ServiceInvocationHandler, an implementation of dynamic proxy MethodInvocation interface, inspects method calls on proxy interface and routes calls appropriately either to service implementation class or dao implementation class. A sample spring configuration would look like this –
ConclusionThough the article here quotes service/dao interation, but the idea can used in service composition or to combine a core service and many decorating services around it.