Strategie per gestire un framework C # modulare

Question

Strategie per gestire un framework C # modulare

#1 da (1 voti)

1

Attualmente sto costruendo un grande framework il cui scopo è quello di eseguire diversi algoritmi in sequenza.

Molti di questi algoritmi hanno interdipendenze nella struttura dei dati - l'output di un algo è l'input di un altro algo, ad esempio MagicVectorXY. Gli algoritmi devono essere modulari e compatti, poiché alcuni di questi algoritmi saranno riutilizzati in molti altri framework separati. E vogliamo evitare il più possibile il codice irraggiungibile.

La nostra soluzione attuale è quella di compilare ciascun algoritmo nella sua .dll, mentre le interfacce condivise / le librerie matematiche di terze parti / le strutture di dati condivise risiedono in un CommonInterfaces.dll. Tuttavia, questo porta alla proliferazione di progetti nella soluzione di Visual Studio, e c'è ancora un codice irraggiungibile significativo in CommonInterfaces.dll.

Quali altre strategie ci sono per gestire un framework così modulare?

PS: prevediamo ~ 10 algoritmi, e cose come il livello database, WCF, scheduling e test unitari per ogni progetto sono anch'essi tutti progetti propri. Quindi circa 25-30 progetti stimati in quella singola soluzione.

c# visual-studio dependency-management

posta Cardin 12.06.2015 - 07:41

fonte

1 risposta

Leggi altre domande sui tag c# visual-studio dependency-management

Controlli di autorizzazione a livello di campo per l'API REST: questa convalida? DDD Request Validation Handling

score 1 · Accepted Answer

Le informazioni qui sono un po 'scarse ...

Prima di tutto (se non lo hai già fatto) potresti voler controllare SOLID . Il susseguirsi di queste regole darà al tuo software una buona struttura di dipendenza. Una buona struttura di dipendenza è la chiave per poter scambiare i moduli dentro e fuori. (E non avrai bisogno di fare riferimento al datalayer per compilare i tuoi algoritmi)

Ciò che mi colpisce di più nella tua descrizione sono le "interfacce condivise". Per rendere ciascun algoritmo un vero modulo, ogni modulo deve definire singolarmente le interfacce che utilizza. Vedi ISP . Quindi l'implementazione delle diverse interfacce può essere in una singola classe che fa riferimento all'algoritmo .dll: s ma è anche possibile fornire diverse implementazioni per diversi framework, se necessario. O forse hai un'implementazione predefinita che puoi impacchettare con il modulo.

Inoltre, non aver paura di aggiungere progetti. E suggerirei di pensare a strutturare il codice in base alla funzionalità (modulo / algoritmo / ecc.) Anziché a livelli diversi, in quanto ciò consentirà, ad esempio, di selezionare le parti del livello dati di cui si ha bisogno.