Risorse per la progettazione di strutture .dll

Question

Sono appena uscito da una riunione di design e mi è stata posta una domanda su dove ho avuto una delle mie idee su come strutturare alcuni .dll di un progetto che stiamo realizzando. Ad essere sincero, non ho idea di dove sia questa "idea". è venuto da me mi è sembrato una conoscenza naturale. Tuttavia sarebbe utile se potessi sostenere queste opinioni con alcune analisi documentate.

Qualcuno sa delle risorse che esplicitamente discutono meccanismi diversi per strutturare assiemi / moduli / sorgente?

UPDATE:

Beh, l'idea non era niente di speciale. Stavamo discutendo di un livello di astrazione per alcuni componenti hardware, quindi l'app "quotata" che consuma questi servizi potrebbe essere (sorta di) indipendente dalla piattaforma. In precedenza avevamo un'interfaccia .dll che dichiarava le interfacce richieste dall'app e un'implementazione .dll che le implementa per l'unica piattaforma che abbiamo avuto finora. Ora abbiamo due piattaforme ma sono molto simili. Per evitare che le interfacce .dll vengano inquinate o uno scenario orribile in cui le implementazioni fanno riferimento l'una all'altra, ho semplicemente suggerito di creare un altro .dll che si trova tra le interfacce e specificplatform.dll dove possono vivere implementazioni astratte comuni.

Answer 1

Se ne hai la possibilità, dai un'occhiata al libro di Robert C. Martin:

Principi, schemi e pratiche agili in C # (Questa è la nuova versione specificamente indirizzata a .Net)

C'è un capitolo dedicato alla progettazione dei componenti che (probabilmente) risponde alla tua domanda.

In sintesi, e dopo aver letto quel libro, consiglio sempre di separare i componenti in base a questi criteri:

• Gli assiemi sono unità o riutilizzano : se ci sono classi che devono essere usate insieme, vanno nello stesso assieme.

• Gli assembly sono unità di modifica : se ci sono classi che non devono cambiare per lo stesso motivo, probabilmente non dovrebbero essere nello stesso assembly.

• Gli assembly sono unità di distribuzione : se ci sono classi che devono essere distribuite fisicamente nello stesso posto, probabilmente dovrebbero andare nello stesso assembly.

Naturalmente si tratta solo di euristica e non di ricette. Alla fine è necessario decidere la quantità di ciascuna di queste tre euristiche di progettazione necessarie in base agli obiettivi architetturali della propria applicazione (in particolare gli obiettivi architetturali per la distribuzione e l'evoluzione / modifica).