I'm using the GenericDao approach discussed provided by appfuse.
I have a DAO that is used to persist/get ElectronicFormsConfirmationDetails
objects, where ElectronicFormsConfirmationDetails extends
ConfirmationDetails:
public class ElectronicFormsConfirmationDetails extends ConfirmationDetails
{
private DocumentDeliveryPreferences documentDeliveryPreferences;
...
}
public class ConfirmationDetails extends IDObject {
private TaxEntity taxEntity;
private Confirmation confirmation;
private ElectionEvent electionEvent;
private ActiveStatus activeStatus;
private ConfirmationType confirmationType;
...
}
public interface ElectronicFormsConfirmationDetailsDao extends
GenericDao<ElectronicFormsConfirmationDetails, Long> {
public ElectronicFormsConfirmationDetails findCurrentElection(
TaxEntity taxEntity);
}
Now I'm going to have additional ConfirmationDetails types that will extend
ConfirmationDetails, for instance:
public class ServiceProviderConfirmationDetails extends ConfirmationDetails
{
private AccessType accessType;
private ServiceProvider serviceProvider;
private boolean participating;
...
}
And its associated DAO will have many shared methods (but will certainly
have some that are unique to ServiceProviderConfirmationDetails):
public interface ServiceProviderConfirmationDetailsDao extends
GenericDao<ServiceProviderConfirmationDetails, Long> {
public ServiceProviderConfirmationDetails findCurrentElection(
TaxEntity taxEntity);
}
I'm finding that I'm generating a great deal of similar code due to this
scenario, so I was thinking of creating a ConfirmationDetailsDao, having it
extend GenericDao and having the ServiceProviderConfirmationDetailsDao and
ElectronicFormsConfirmationDetailsDao extend that:
public interface ConfirmationDetailsDao extends
GenericDao<ConfirmationDetails, Long> {
public ConfirmationDetails findCurrentElection(
TaxEntity taxEntity);
}
public interface ElectronicFormsConfirmationDetailsDao extends
ConfirmationDetailsDao {
//Nothing yet
}
public interface ServiceProviderConfirmationDetailsDao extends
ConfirmationDetailsDao {
//Nothing yet
}
This way, using Hibernate's polymorphism support, I would think I wouldn't
need to write specific findCurrentElection methods for each
ConfirmationDetails DAO type.
However, I'm not sure this approach is going to work. For instance, if I
try to retrieve a ElectronicFormsConfirmationDetails object, using my
ElectronicFormsConfirmationDetailsDao:
ElectronicFormsConfirmationDetails confirmationDetails =
electronicFormsConfirmationDetailsDao
.findCurrentElection(taxEntity);
I receive the following compile-time error: "Type mismatch: cannot convert
from ConfirmationDetails to ElectronicFormsConfirmationDetails"
This makes sense, obviously, as my method signature for my
ElectronicFormsConfirmationDetailsDao, returns a ConfirmationDetails object
as it is declared in the ConfirmationDetailsDao object. I can cast the
object and the code works:
ElectronicFormsConfirmationDetails confirmationDetails =
(ElectronicFormsConfirmationDetails) electronicFormsConfirmationDetailsDao
.findCurrentElection(taxEntity);
But it feels like a clunky solution to the problem. How can the client know
for sure that the returned ConfirmationDetails object is a
ElectronicFormsConfirmationDetails subclass?
Does anyone have any suggestions on my approach? Is there a better way I
can cut down on the redundancy in my DAO code, while not requiring the
client to cast calls?
Thanks for your help!
Leo
--
View this message in context:
http://www.nabble.com/GenericDao-and-Class-Hierarchy---Approach--tp14672300s2369p14672300.html
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
