Hai bisogno di consigli sul design del framework: come estendere facilmente

Question

Hai bisogno di consigli sul design del framework: come estendere facilmente

#1 da (1 voti)
#2 da (0 voti)

3

Sto creando un framework / libreria per un caso d'uso piuttosto specifico (tipo di dati). Usa diversi componenti della molla, inclusi i dati di molla. La libreria ha una serie di classi di entità correttamente configurate e in base ai livelli di servizio e dao. Il lavoro principale o il vantaggio principale del framework si trova nel livello dao e servizio.

Gli sviluppatori che utilizzano il framework dovrebbero essere in grado di estendere le mie classi di entità per aggiungere campi aggiuntivi di cui hanno bisogno. Pertanto ho creato dao e service layer generico in modo che possa essere utilizzato da tali classi di entità estese.

Ora sto affrontando un problema nella parte IO del framework. Deve essere in grado di importare il secondo "tipo di dati speciali" nel database. In questa parte ho bisogno di creare una nuova istanza di entità e quindi ho bisogno della classe effettiva utilizzata. La mia soluzione attuale è quella di configurare in primavera un bean della classe effettiva utilizzata. Il problema è che un'applicazione che usa il framework può usare solo 1 implementazione dell'entità (quella originale da me o esattamente 1 sottoclasse ma non 2 diverse classi della stessa gerarchia.

Sto cercando suggerimenti / progetti per risolvere questo problema. Qualche idea?

EDIT:

l'unica idea che ho è di aggiungere un parametro ai metodi interessati che accetta un oggetto Class. Questa sarebbe la soluzione facile e pragmatica ma sembra molto brutta?

design java frameworks spring generics

posta beginner_ 07.11.2012 - 12:13

fonte

2 risposte

1

Qui la mia soluzione attuale è venuta fuori dopo alcune ricerche. Ma per favore pubblica anche le tue soluzioni.

Sono andato con il mio suggerimento nella modifica di cui sopra. Tuttavia, solo i metodi interessati nel DAO richiedono questi parametri aggiuntivi (nel mio caso 2 oggetti java.lang.Class). DAO e Service Classes rimangono generici.

Il trucco, tuttavia, è di aggiungere un costruttore alla classe di servizio che accetta come parametro questi 2 parametri oggetto di classe. Quindi nella configurazione di Spring è necessario creare un bean di servizio per classe nella gerarchia che si desidera utilizzare. Esempio:

<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>

dove i bean di riferimento sono oggetti di classe creati in questo modo:

<bean id="CompoundClass" class="java.lang.Class" factory-method="forName">
    <constructor-arg value="full.qualified.class.name"/>
</bean>

Mentre i metodi interessati sono ora un po 'disordinati (molti argomenti) e passare oggetti Class mi sembra non ideale (probabilmente mi sbaglio) uno sviluppatore che usa il framework non dovrà affrontare il problema. Può creare le sue entità estese e applicare la configurazione corretta. Ho creato test per la sua e la soluzione che sembrano funzionare come previsto.

Se CompoundClass2 estende CompoundClass (che utilizza @DiscriminatorColumn) e chiamo un metodo di query da MyServiceImpl, solo gli oggetti CompoundClass2 sono nel risultato anche se un oggetto CompoundClass corrisponde anche alla query + viene restituito il tipo corretto. Nessuna fusione necessaria.

risposta data 08.11.2012 - 16:21

fonte

Leggi altre domande sui tag design java frameworks spring generics

Passando variabili da PHP a C ++ Gestione dei veicoli a rilascio complesso

score 0 · Accepted Answer

Ora utilizzo una soluzione completamente diversa, ovvero per ciascuna entità deve essere creato un servizio separato. Questo servizio può estendere quello fornito dal mio framework e facoltativo aggiungere metodi aggiuntivi. Questo risolve la configurazione di cui sopra perché non hai più bisogno di alcun argomento di costruzione:

<bean id="testCompoundService"  autowire="byType"
      class="TestCompoundServiceImpl">
</bean>

<bean id="registrationCompoundService"  autowire="byType"
      class="RegistrationCompoundServiceImpl">
</bean>

e il costruttore predefinito:

public TestCompoundServiceImpl() {
    super(TestCompound.class);
}