Una o più? [duplicare]

Question

Una o più? [duplicare]

#1 da (4 voti)

2

Al momento ho una dll "library" che ha un modulo per ogni argomento: Text, Reflection, Security, Math, FileSystem, FTP, Mail, Serialization, ecc.

In ogni modulo sono metodi di supporto pubblico che possono chiamare metodi di framework .Net o altri metodi di supporto.

In passato, ho avuto più dll, ognuna dedicata a un argomento. Ciò si è rivelato molto più difficile da gestire in quanto vi era una certa interdipendenza tra le DLL (perché non utilizzare i metodi di libreria all'interno della libreria?), E sarebbero andati fuori sincrono. Per non parlare, le dipendenze circolari non sono consentite.

Questa è la mia libreria e puoi vedere la dipendenza circolare in un caso

Hodifficoltàacoglierequesto:

"Uncle Bob" Martin of Clean Code:

The Release Reuse Equivalency Principle: The granule of reuse is the granule of release.

Qual è il miglior standard architettonico per l'organizzazione di una libreria di moduli?

architecture .net

posta toddmo 17.02.2015 - 03:04

fonte

1 risposta

Leggi altre domande sui tag architecture .net

Global gitignore v project [closed] Come si implementa un sistema di sessioni attive come LinkedIn? [chiuso]

score 4 · Accepted Answer

Chiedi a te stesso se ha senso che un consumatore di una libreria utilizzi una parte di essa senza utilizzarne un'altra .

Supponiamo che tu abbia sviluppato una libreria che analizza i file MENO , elabora i file MENO in file CSS non minificati e riduce i file CSS.

Ha senso avere una libreria che fa solo l'analisi? Per uso generale, non proprio. Ma ha perfettamente senso per una persona che vuole, ad esempio, creare un linter per file LESS.
Ha senso avere una libreria che esegue solo l'elaborazione? Probabilmente no. OK, potrebbe essere che qualcuno scriva un parser che è più veloce e migliore del tuo, ma questa persona probabilmente scriverà anche il suo motore di elaborazione. Pertanto, un processore senza parser non è molto utile.
Ha senso avere una libreria che minimizza i CSS e ignora tutto ciò che riguarda LESS? Completamente.

Di conseguenza, non abbiamo una sola, ma due librerie:

MENO parser e processore, che dipende da ...
... minificatore CSS.

Perché due anziché tre? Bene, l'uso generale, come spiegato in precedenza, consiste nell'usare insieme il parser e il processore. C'è un raro caso in cui il parser può essere usato indipendentemente, questo non giustifica il costo di creare due librerie (sebbene tu o la tua squadra potreste decidere che tale caso è ancora importante e dovreste avere due librerie separate).

In pratica:

Se ti vedi costantemente includendo due librerie affiancate e praticamente non ci sono casi in cui ne includi uno senza altro (o viceversa nel caso in cui ci sia una dipendenza), unisci le librerie.
Se utilizza costantemente solo una parte della libreria e questa parte sembra essere logicamente distinta dalle altre parti, dividi la libreria.

Ho notato anche alcuni punti che voglio evidenziare ma che non sono correlati alla domanda stessa. Consideralo una sorta di commento:

Hai esaminato l'organizzazione di .NET Framework stessa?
Le "funzioni pubbliche che racchiudono le funzioni di .NET Framework" fanno paura. Perché tutto questo funziona? Qual è il punto nel chiamare i tuoi metodi invece di quelli di .NET Framework?
Le funzioni e i metodi non sono la stessa cosa. Credo che tu stia prendendo dei metodi qui.
Se si ottengono dipendenze circolari, potrebbe indicare che l'architettura è profondamente errata.
Con la nuova nave intendi una riscrittura completa? In caso affermativo, potresti essere interessato a un articolo di Joel Spolsky .