Quali sono i problemi con una libreria comune relativamente grande?

3

Finché il codice nella libreria di base è accoppiato in modo lasco come se lo dividesse in librerie separate, qual è il problema? In generale, avere un sacco di assiemi che compongono una soluzione .NET è doloroso.

Inoltre, quando il codice in una soluzione deve essere condiviso, può essere semplicemente aggiunto alla libreria comune, piuttosto che decidere quale libreria comune deve essere aggiunta o creare un'altra libreria.

modifica: la domanda mi viene dopo aver usato Smalltalk per un po ', dove tutto il codice è sempre disponibile per l'uso.

    
posta xofz 02.03.2011 - 00:53
fonte

3 risposte

1
  • Sicurezza, controllo delle versioni e dipendenze sono alcune preoccupazioni.

  • Mi piace mantenere il codice che fa riferimento o importa altre librerie (in particolare le librerie di terze parti) il più possibile isolate, non solo logicamente, ma anche fisicamente. Ciò aiuta a rafforzare / incoraggiare le preoccupazioni logiche di coesione e accoppiamento.

  • Test di praticità. Carico e tempo di esecuzione di un piccolo assieme e dell'assemblaggio di test corrispondente rispetto a un assieme di grandi dimensioni e un gruppo di test di grandi dimensioni.

  • Gli aspetti fragili o volatili sono più facili da identificare e concentrarsi su

  • Estensibilità e distribuzione. Interfaccia solo o interfaccia principalmente progetti sono belli per la creazione di estensioni a valore aggiunto. Perché distribuire un componente di grandi dimensioni, quando è possibile eseguire piccole dimensioni?

risposta data 06.03.2011 - 08:21
fonte
2

Ci sono 4 cose da considerare: separazione di compiti, importanza, dipendenze e dimensioni.

Assiemi, cartelle / pacchetti, classi, funzioni, blocchi - hanno tutti questo in comune.

Una regola generale per le dimensioni di un determinato argomento:

  • > 1 class = folder / subfolder.
  • > 5-10 classi = sottocartelle.
  • > 15-25 classes = assembly.

La mia convinzione è che lo scopo delle classi è più importante della dimensione.

Un esempio di vita reale:

Ho scritto una libreria di analisi della riga di comando molto semplice. Questo finì per essere 3 classi in una cartella "CommandLine" in un assembly di libreria comune ... non era così importante e l'ho usato in due progetti correlati.

Quindi ho dato la fonte di quelle lezioni per aiutare qualcuno con il loro progetto. Qualcun altro l'ha visto e ha suggerito di aggiungere il supporto per gli attributi. Ho colto l'occasione per rifattorizzare il codice, aggiungere test unitari e renderlo una libreria molto più avanzata. Quando lo facevo, l'ho spostato sul proprio assembly in modo da poterlo lavorare autonomamente per diverse notti e per le sue dimensioni, importanza e riutilizzabilità al di fuori della mia libreria comune.

Perché molti assembly sono dolorosi in .net? Direi che l'implementazione e la creazione di nuovi progetti sono marginalmente più difficili con più riferimenti.

Basta aggiungere un progetto esistente alla soluzione e un "riferimento al progetto" per i progetti che dipendono da esso. Fatto.

Potrei vedere un riferimento assemblato compilato come un onere dovuto alla creazione, copia e test in ogni soluzione, ma tu hai l'origine, quindi aggiungi il progetto alla tua soluzione.

    
risposta data 02.03.2011 - 02:46
fonte
1

Non vedo alcun problema finché le diverse librerie contengono oggetti correlati. Se appartengono insieme, appartengono insieme. Niente di "troppo grande" in questi casi.

    
risposta data 02.03.2011 - 00:56
fonte

Leggi altre domande sui tag