[C# - 4.0] Gestione aggiornamenti software che può essere personalizzato da clienti

[rsdpzed]

Piuttosto che l'ereditarietà potresti sfruttare il concetto di ui composition.
Separi le funzionalità della pagina in usercontrols (o custom controls) separati fino ad arrivare al risultato per cui l'applicazione web è solo il guscio che contiene gli uc.
Bisogna avere cura di scrivere negli uc SOLO il codice relativo alla loro "presentazione" e mai codice "intelligente" per la risoluzione dei problemi di business. Per le problematiche di Business devi fare riferimento ad una dll separata.
A questo punto l'applicazione diventa il solo un template di base.
Il livello di personalizzazione è completo su questa applicazione web finche non si toccano gli uc, inoltre:
Gli uc possono essere modificati in termini di look and feel (themes, css, ecc)
Gli uc possono essere riscritti in termini di funzionalità usando le classi di business contenuti in ddl separate. Questa operazione è possibile perche come ho detto su la logica interna all'uc originale contiene solo logica di presentazione. Chi riscrive l'uc lo fara utilizzando LE STESSE classi di business che hai usato tu.

A qusto punto il livello di personalizzazione successivo sono le classi di business vere e proprie. Qui entra in gioco l'ereditarietà.

Un esempio pratico.
metti che hai una pagina aspx che visualizza una fattura. Tra i vari usercontrol che compongono la pagina c'è quello del riepilogo (totale fattura). Metti che lo hai programmato per visualizzare solo il totale e che un cliente vorrebbe personalizzare la pagina per calcolare e visualizzare anche imposta e imponibile.
Per prima cosa deve estendere la classe di business per fare in modo che la classe che calcola il totale calcoli anche il totale imposta e il totale imponibile, e questo lo fa ereditando la classe.
Poi deve riscrivere l'uc inserendo ulteriori due textbox i cui risultati sono calcolato non nell'uc stesso ma dalle classi di business (quelle estese che ora contengono i metodi). insisto sulle classi di business separate non solo perchè è giusto separare la logica dalla presentazione ma anche per facilitare la vita del programatore terzo che riscriverà l'uc.
E fine...

A parole sembra facile, la parte piu difficile nel mettere in pratica questo pattern è mantenere le uc indipendenti tra loro anche quando devono collaborare strettamente tra loro. Se ci pensi è quello che gia fa asp.net con i controlli i quali espongono proprietà pubbliche e comunicano tra loro non direttamente ma attraverso gli eventi.

[Stoicenko]

Che è la stessa cosa che cercavo di dire io.

In un progetto web non è possibile gestire una vera e propria ereditarietà delle pagine.

La cosa migliore è dividere il progetto tra view, model e controller (usando il pattern MVC) o, ancora meglio, in View, ViewModel, Model (usando il pattern MVVM).

Con questo tipo di divisione la parte di business rimane "isolata" dalla parte di visualizzazione rendendo così "espandibile" entrambe le parti senza pregiudicare le funzionalità di base.

Ovviamente questo comporterà una complessità maggiore a te (che devi operare una divisione "strict" del tuo progetto) e ai clienti che, per ogni modifica, dovranno estendere le classi di business e modificare le view di conseguenza (oltre che i controller o i ViewModel).

Comunque, se vuoi un esempio ottimo, ti rinnovo il consiglio di guardarti il progetto DotNetNuke.

[WebMinus]

Grazie mille ragazzi, siete stati disponibilissimi. Approfondirò sicuramente gli argomenti che mi avete consigliato. Purtroppo non ho molto tempo in questi giorni, ma appena ne troverò un po' da dedicare a questo discorso, sono sicuro che studiando mi verranno mille domande da farvi. Per ora invece non mi resta che studiare.
Grazie ancora.