On Jan 7, 2008 6:11 PM, leojhartiv <[EMAIL PROTECTED]> wrote:
>
> 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?
The simplest solution would probably be to use generics as per the
GenericDao. So instead of
public interface ConfirmationDetailsDao extends
GenericDao<ConfirmationDetails, Long>
Do something like
public interface ConfirmationDetailsDao<T extends ConfirmationDetails>
extends GenericDao<T, Long>
Mike
>
>
>
> 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]
>
>
