Ho più progetti correlati in una soluzione di Visual Studio C #, che in generale hanno un'architettura simile dei servizi di business logic di WCF e dei client ASP.NET.
Per ospitare questi servizi, ho implementato l'applicazione personalizzata ServiceHosting , che legge l'associazione e le impostazioni delle porte, l'elenco dei servizi e le impostazioni di NInject dal file App.config e ospita questi servizi.
Poiché tutte queste impostazioni variano da progetto a progetto, in ogni "sottoprogetto" ho un progetto come "ServiceHosting.Project1", che ha un solo file "App.config" contenente configurazioni specifiche del progetto. Come impostazioni di avvio del progetto, ho specificato ServiceHosting.exe con la directory di lavoro di questo progetto di configurazione.
Quindi, in generale, sembra:
Project 1
- Project1.Domain (contains business logic, class library)
- Project1.ServiceHosting (contains configuration only, runs Tools/ServiceHosting)
Project 2
- Project2.Domain (contains business logic, class library)
- Project2.ServiceHosting (contains configuration only, runs Tools/ServiceHosting)
Tools
- ServiceHosting (application. you may run this, but no App.config will be found)
Tuttavia, avere un progetto con un file di configurazione ha un cattivo odore per me.
E 'considerato un difetto di architettura?
In precedenza, avevo un altro approccio: invece di usare il file di configurazione, ServiceHosting.cs era una classe astratta; Project1.ServiceHosting e Project2.ServiceHosting contenevano i suoi tipi derivati con metodi overriden personalizzati GetServices , LoadNinjectModules e GetBinding .
Tuttavia, questo sembrava violazione DRY.