Dove devo posizionare la mia interfaccia?

Naviga le tue risposte
5

Ho un'interfaccia per comunicare con un DB (in realtà non è un database, ma questo per dare un esempio concreto): 

interface DbInterface{
    Result sendQuery(Query q);
}

E sto cercando di migliorare la riusabilità separando componenti specifici in singoli progetti:

  • App1, un'applicazione che richiede l'accesso a un database
  • App2, un'applicazione che richiede l'accesso a un database
  • DB1, un'implementazione concreta di DbInterface (diciamo SQL)
  • DB2, un'implementazione concreta di DbInterface (diciamo usando un database NoSql)

Come si progetta in genere una tale architettura e dove dovrebbe essere posizionato DbInterface ?

  • in una delle applicazioni? ma ciò significa che tutti gli altri tre componenti dipendono da quel progetto per accedere all'interfaccia - non suona bene
  • in una delle implementazioni DB? stesso - non suona bene.
  • in entrambe le implementazioni DB? duplicazione del codice.
  • in un progetto separato, che conterrebbe solo quell'interfaccia? sembra abusivo includere una dipendenza solo per un'interfaccia.

Per riferimento, questo è Java + Maven, ma il problema è abbastanza generico, suppongo.

    
posta assylias 04.09.2013 - 14:47
fonte

3 risposte

6

Le interfacce sono ciò che usi per definire un contratto tra le applicazioni e l'implementazione. Questo contratto è solitamente gestito da un progetto intermedio denominato API o SDK.

L'applicazione utilizza interfacce dall'SDK e il progetto DB1 implementa tali interfacce, ma è il progetto SDK che definisce tali interfacce.

    
risposta data 04.09.2013 - 15:18
fonte
6

Personalmente andrei con il progetto separato. Praticamente ogni progetto su cui ho lavorato ha avuto una sorta di progetto / libreria "comune" a cui tutti gli altri fanno riferimento.

Anche se probabilmente è eccessivo solo per una singola interfaccia, sembra probabile che in futuro potrebbero esserci casi simili e, quando ciò accade, hai già un posto dove metterli.

Non conosco i dettagli delle tue applicazioni, ma non ci sono classi di supporto ecc. che potrebbero essere di beneficio per entrambi i progetti che potrebbero anche essere inseriti in un progetto comune?

    
risposta data 04.09.2013 - 15:06
fonte
3

Un progetto separato sarebbe il migliore in questo scenario. Anche se ora conterrà solo un'interfaccia singola, potrebbe crescere. Normalmente questo tipo di progetto è chiamato qualcosa come "API". Non c'è motivo per cui un progetto come questo non possa contenere alcuna logica (ad esempio, se si desidera fornire una facciata su interfacce API disparate), ma non dovrebbe essere specifico per l'implementazione.

La maggior parte delle applicazioni dovrebbe basarsi solo su questo progetto API come dovrebbe essere codificato per interfacce in ogni caso. Solo i progetti che fanno parte di una sorta di implementazione specifica dovranno conoscere le implementazioni dell'API. Nelle moderne applicazioni che utilizzano ampiamente DI, l'implementazione di solito è solo un problema di runtime.

Esempi abbondano nel regno di Java. JPA e Apache Commons Logging (o qualsiasi altra API di registrazione) sono una coppia con cui probabilmente hai già lavorato.

Per quanto riguarda il tuo commento "sembra abusivo includere una dipendenza solo per un'interfaccia" . Posso vedere come ci si sente un po 'imbarazzati la prima volta che lo incontri, ma direi che è più abusivo includere le dipendenze di cui non hai bisogno in un progetto come faresti se dovessi includere l'implementazione per ottenere solo l'interfaccia.

    
risposta data 04.09.2013 - 15:39
fonte

Leggi altre domande sui tag

Quali tipi di processi devono essere riflessi nel diagramma di flusso? Come faccio a gestire un numero così elevato di query SQL?