SharePoint e Architettura...why not? #1

Una volta qualcuno mi ha chiesto "Ma perchè ti interessi di Architettura (del software nda)? Tu mica lavori con SharePoint?".

A parte il fatto che fortunatamente non lavoro solo con SharePoint, non capisco dove sia il nesso. Una buona architettura ti aiuta. Sempre. (dove per buona non intendo che la sua bontà sia direttamente proporzionale alla sua cardinalità, per non dire complessità).

Detto questo volevo portare questo mio esempio (niente codice, solo teoria quindi, veri coders, cambiate pure post :D) senza avere nessuna pretesa, solo come case study (addirittura?).

Mesi fa, avendo riscontrato una certa ripetitività codice in alcune WebPart da me sviluppate, ho pensato bene di centralizzare il codice che gestisce la generazione e la modifica di codice CAML in una libreria a se stante, referenziandola poi in tutte le WebPart che ne avessero avuto bisogno.

Il tutto funzionava perfettamente e avere il codice centralizzato è un grosso vantaggio.

Forse.

La centralizzazione è in realtà un boomerang se va di pari passo con la dipendenza.

Eh si...perchè se cambio qualcosa, qualsiasi cosa nella libreria centralizzata devo ricompilare tutti i componenti (nel nostro caso, WebPart) che ne fanno uso.

Non sarebbe comodo normalmente, figuriamoci se si parla di WebPart.

Ho capito subito la prima volta che ho sentito parlare di IoC che quella era la strada da percorrere.

Allora ho fatto un po' di refactoring.

Mi sono creato una libreria di "base" contenente solo l'interfaccia del CAML Manager. Questo è l'assembly referenziato da tutte le WebPart.

Il "vero" CAML Manager è ora un'altra libreria che aderisce a quell'interfaccia e che verrà instanziata via reflection dalle WebPart.

Ho ricompilato (per l'ultima volta però...) tutte le WebPart ed ho installato il tutto.

Il vantaggio di tutto questo è che finalmente se devo cambiare qualcosa nella libreria centralizzata, non è più necessario che ricompili chi la utilizza (fintanto che non cambio anche l'interfaccia, ovviamente, ma quella si spera non cambi tanto facilmente).

Obiettivo raggiunto.

Spero di completare questo post con uno più di dettaglio.

Print | posted @ mercoledì 17 dicembre 2008 03:15

Comments on this entry:

Gravatar # Esempio di dependency injection (DI) in C++… « JP’s Web Place
by Pingback/TrackBack at 19/01/2009 10:43

Esempio di dependency injection (DI) in C++… « JP’s Web Place
Comments have been closed on this topic.