2009-10-28 9 views
8

La mia domanda non riguarda tanto l'uso delle interfacce, quanto piuttosto la natura di un progetto organizzativo.Le interfacce dovrebbero essere in un progetto separato dalla loro implementazione?

Nota: sto utilizzando VisualStudio in un'applicazione a più livelli.

I file del mio interfaccia devono essere inseriti in un progetto separato dalle rispettive implementazioni? Il mio pensiero iniziale è che sarebbe utile separare tutte le mie interfacce di servizio nel proprio progetto (e un progetto per le mie implementazioni iniziali) in modo che lungo la strada l'implementazione/progetto concreto possa essere rimosso e sostituito con uno nuovo se necessario.

Per chiarire con un esempio: Supponiamo di avere un'interfaccia del livello aziendale denominata IBusinessService che risiede nello spazio dei nomi MyApp.Business.Services. La mia implementazione FooBusinessService esisterebbe nello stesso spazio dei nomi, ma un progetto diverso in VisualStudio. Se in seguito l'implementazione dovesse essere rielaborata, uno sviluppatore potrebbe rimuovere il riferimento a FooService.proj e sostituirlo con un riferimento a BarService.proj.

Sembra che questo declutter la soluzione dell'app consentendo di fare riferimento a un progetto con solo interfacce senza acquisire anche implementazioni concrete (che potrebbero essere obsolete o inutili), ma mi manca qualcosa?

+0

possibile duplicato di [Devo avere un assembly separato per le interfacce?] (Http://stackoverflow.com/questions/3363312/should-i-have-a-separate-assembly-for-interfaces) – nawfal

risposta

10

Sono con voi. Preferisco inserire le mie interfacce in un progetto separato AND in un namespace diverso. L'esempio classico è con le classi di accesso ai dati. Vuoi essere in grado di codificare una versione MSSQL e una versione MySQL, entrambi implementando la stessa interfaccia. Pertanto, preferisco che la definizione dell'interfaccia sia in un assembly/progetto separato. Ecco un esempio di come i lay out assembly e spazi dei nomi:

  • Elder.DataAccess.Core - contiene le interfacce e le utilità comuni
  • Elder.DataAccess.MSSQL - specifiche implementazioni MSSQL delle interfacce
  • Elder. DataAccess.MySQL - implementazioni MySQL specifiche delle interfacce

Ciò consente di modificare le implementazioni senza toccare il progetto che contiene le definizioni dell'interfaccia. Questo mi aiuta anche con il controllo della versione e il rilevamento delle modifiche. Ci potrebbero essere altri modi per scuoiare questo gatto, quindi sarò desideroso di vedere le risposte di altre persone.

+1

Grazie Scott. Questa è la struttura che sto usando ora, volevo solo una conferma che avesse senso e che non mi mancasse qualcosa. A meno che qualcun altro non indichi un difetto - lo farò per le mie interfacce. –