Quali sono i motivi per le librerie di ricostruzione e di ridistribuzione?

Question

Quali sono i motivi per le librerie di ricostruzione e di ridistribuzione?

#1 da (2 voti)

0

È difficile capire il significato della domanda dal nome dell'argomento.

Ecco cosa intendo.

Sto guardando Episodi di codice pulito di Uncle Bob. In molti episodi in cui sta parlando dei principi SOLID, egli menziona il problema della ricostruzione e della ridistribuzione causata dal cambio di codice. Dice che una cattiva architettura causa frequenti ricostruzioni e ridistribuzioni.

Ma ho un paio di domande:

Perché frequenti ricostruzioni e ridistribuzioni è sbagliato?
Puoi enumerare le cause di ricostruzioni e ridistribuzioni di dll?
C'è qualche differenza tra lingue diverse secondo il seconda domanda?
Quali sono le cause della ricostruzione e della ridistribuzione di dll in C #?

La seconda domanda (e la più comune) si basa sull'accoppiamento di dll. Cosa dovrei cambiare in una delle due dll accoppiate, quindi devo ricostruire e ridistribuire l'altra?

design c# architecture solid .net

posta EngineerSpock 18.03.2013 - 19:14

fonte

1 risposta

Leggi altre domande sui tag design c# architecture solid .net

Come si fa la moltiplicazione scalare e la matrice inversa quando le variabili sono di dimensione 1000 bit? Comprime l'intervallo di numeri in blocchi di usato o inutilizzato

score 2 · Accepted Answer

Perché è un lavoro extra e una fonte di potenziali errori. Se non è necessario distribuire, non c'è possibilità di errore nel processo di distribuzione. La distribuzione può essere costosa se devi rimuovere uno o più server per farlo.
Qualsiasi cosa che cambia una DLL causerà una ricostruzione e la ridistribuzione. Specificamente, se apporti una modifica al codice della DLL, dovrai ricostruirlo e ridistribuirlo (assumendo che la modifica sia significativa e desiderabile).
Alcune lingue come Erlang hanno funzionalità di "hot deploy", il che significa che non è necessario rimuovere il server o il dispositivo per implementare le modifiche. Questo è utile per cose come interruttori di telefonia e semafori che devono essere in esecuzione 24x7.
Vedi 2.

La cattiva architettura, dal punto di vista dello zio Bob, significa che il codice è troppo strettamente accoppiato. Il codice che è troppo strettamente accoppiato causa un aumento delle ricostruzioni e delle distribuzioni, perché il codice ha troppe dipendenze da altri codici nelle altre DLL. Di conseguenza, apportare modifiche a una DLL spesso si sovrappone alle modifiche richieste in altre DLL.