I’m creating a framework/library for a rather specific use-case (data type). It uses diverse spring components, including spring-data. The library has a set of entity classes properly set up and according service and dao layers. The main work or main benefit of the framework lies in the dao and service layer.
Developers using the framework should be able to extend my entity classes to add additional fields they require. Therefore I made dao and service layer generic so it can be used by such extended entity classes.
I now face an issue in the IO part of the framework. It must be able to import the according “special data type” into the database. In this part I need to create a new entity instance and hence need the actual class used. My current solution is to configure in spring a bean of the actual class used. The problem with this is that an application using the framework could only use 1 implementation of the entity (the original one from me or exactly 1 subclass but not 2 different classes of the same hierarchy.
I’m looking for suggestions / designs for solving this issue. Any ideas?
EDIT:
only idea I have is to add a parameter to the affected methods that takes a Class object. That would be the easy and pragmatic solution but it seems very ugly?
Here my current solution I came up with after some research. But please also post your solutions.
I went with my suggestion in the above edit. However only the affected methods in the DAO require these additional parameters (in my case 2 java.lang.Class Objects). DAO and Service Classes remain generic.
The trick however is to add a Constructor to your Service Class which takes those 2 Class Object Parameters as arguments. Then in the Spring configuration you need to create a service bean per class in the hierarchy you want to use. Example:
<bean id="myService1" autowire="byName"
class="MyServiceImpl">
<constructor-arg index="0">
<ref bean="CompoundClass"/>
</constructor-arg>
<constructor-arg index="1">
<ref bean="CompoundQueryClass"/>
</constructor-arg>
</bean>
<bean id="myService2" autowire="byName"
class="MyServiceImpl">
<constructor-arg index="0">
<ref bean="CompoundClass2"/>
</constructor-arg>
<constructor-arg index="1">
<ref bean="CompoundQueryClass2"/>
</constructor-arg>
</bean>
where the referenced beans are Class objects created like this:
<bean id="CompoundClass" class="java.lang.Class" factory-method="forName">
<constructor-arg value="full.qualified.class.name"/>
</bean>
While the affected methods are now a bit cluttered (many arguments) and passing around Class objects seems non-ideal to me (probably I’m wrong) a developer using the framework will not have to deal with the issue. He can create his extended entities and apply the correct configuration. I’ve created tests for his and the solution those seem to work as expected.
If CompoundClass2 extends CompoundClass (which uses @DiscriminatorColumn) and I call a query method from MyServiceImpl only CompoundClass2 objects are in the result even if a CompoundClass object would match the query too + the right type is returned. No casting needed.
I now use a completely different solution, namely for each entity a separate service must be created. That service can extend the one provided by my framework and optional add additional methods. This gets rids of the configuration above because you don’t need any constructor arguments anymore:
<bean id="testCompoundService" autowire="byType"
class="TestCompoundServiceImpl">
</bean>
<bean id="registrationCompoundService" autowire="byType"
class="RegistrationCompoundServiceImpl">
</bean>
and the default constructor:
public TestCompoundServiceImpl() {
super(TestCompound.class);
}