Necessità di interfaccia separata e impl per DAO

Question

Abbiamo una tipica applicazione java n-tier e ho notato che i nostri livelli di accesso ai dati hanno DAO che sono del tipo FooDAO e FooDAOImpl. Stavo cercando di giustificare la necessità dei due ed ecco la mia analisi.

1. Se si dispone di più implementazioni per la stessa interfaccia, l'astrazione è utile. Ma dato che abbiamo già fatto la scelta del framework da utilizzare per il DAOImpl (ad esempio iBATIS), è davvero necessario?
2. Guida in collegamento tramite Spring. Da quanto ho capito, le classi che hanno interfacce possono essere facilmente condivise (andando sulla rotta JdkProxy) piuttosto che le classi che non hanno interfacce (dove viene scelta la route cglib) e una ha la sottoclasse della classe da proxy. La sottoclasse ha i suoi problemi in cui la classe proxy è definitiva o non ha costruttori predefiniti, entrambi altamente improbabili nel livello di accesso ai dati. Le prestazioni erano un fattore, ma da quello che ho sentito, non è più motivo di preoccupazione.
3. Aiuto in beffa. Le classi con interfacce sono più adatte a essere derise da strutture di derisione. Ho solo sentito questo, ma non l'ho visto in pratica - quindi non posso davvero contare su di esso, ma forse a causa degli stessi fattori menzionati al punto # 2 sopra.

Con questi punti, non sento la reale necessità di un FooDAO e FooDAOImpl separati in cui un semplice FooDAO dovrebbe essere sufficiente. Sentiti libero di correggere qualsiasi punto che ho menzionato.

Grazie in anticipo!

Answer 1

Ho provato # 3 con Mockito ed è stato in grado di simulare POJO senza interfacce. Con gli argomenti menzionati nei paragrafi 1 e 2, sono incline a non andare con DAO e DAOImpl separati per ora. Sentiti libero di aggiungere altri punti di confronto.

Answer 2

vedo una quarta ragione:

• dettagli Nascondi implementazione

ad esempio in base alla squadra, la durata prevista del software o la quantità di cambiamento anticipato in futuro, si paga per nascondere il più possibile anche se esiste una sola implementazione.

Answer 3

Direi che avere un'interfaccia FooDAO con una singola implementazione FooDAOImpl è generalmente un anti-pattern. La soluzione più semplice (nessuna interfaccia separata per DAO) è molto preferibile, a meno che non si abbia una ragione solida altrimenti - il che non sembra essere il caso qui.

Personalmente, andrei anche oltre e direi che avere DAO non è affatto la scelta migliore. Preferisco avere una singola classe di facciata di persistenza implementata su un'API ORM come Hibernate o JPA. Forse iBATIS è troppo basso per quello, però.