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

[WebMinus]

Ciao a tutti.
Scusate la domanda vaga, ma lo chiedo per potermi orientare, per farmi indicare la strada corretta da percorrere per poi approfondire.

Il mio problema (prima volta che incontro questa esigenza) è questo: sto sviluppando una piccola applicazione web in C#, Framework 4.0. Tale applicazione si interfaccerà con un software decisamente più complesso lato desktop. Tale prodotto sarà poi affidato a clienti che saranno anche distributori. A questi ultimi vuol essere concesso di apportare modifiche e personalizzazione da codice, prima della distribuzione.

Il problema sorge quando si presentasse la necessità di una release. Se le personalizzazioni venissero apportate sul codice sorgente, così com'è, al primo aggiornamento verrebbero sovrascritte.

Avete suggerimenti da darmi per evitare questo problema, indiciazioni sulla strada giusta da percorrere?

Un amico che sviluppa però solo lato desktop con delphi mi ha consigliato di usare dei "controlli utente web". Inserendo in un controllo padre il codice originale e facendo ereditare il controllo stesso ad un controllo figlio, su cui a questo punto è possibile applicare le modifiche. Il problema è che non so se sia possibile. Il massimo sarebbe ereditare l'intera pagina aspx. Insomma, non so bene da dove iniziare.

Grazie a tutti in anticipo.

[Stoicenko]

E' chiaro che, in questi casi, è difficile trovare una strada semplice.

La cosa migliore è inserire tutta la parte "core", cioè la parte più critica che subirà la maggior parte della manutenzione e/o delle modifiche, in dll separate referenziate poi dal tuo progetto web.

In questo modo impedisci che ti modifichino il "motore" dell'applicazione web.

I clienti, per poter modificare il motore, sarebbero così costretti ad "estendere" o "ereditare" le tue classi di gestione (tutte nelle dll).

In questo modo le funzionalità base sono sempre sotto il tuo controllo. Sarà loro premura, in caso di aggiornamenti, controllare che le moro modifiche funzionino ancora correttamente.

[WebMinus]

Questa soluzione però, da come l'ho capita, mi permette di mantenere una ereditarietà tra classi "core" e classi "personalizzabili, ma per quanto riguarda la pagina aspx vera e propria in questo modo non riesco ad ereditarla, è corretto?
Provo a spiegare meglio: tutta la mia libreria di classi estendibile, che sta dietro alla pagina web, è perfettamente ereditabile, ma la pagina aspx, con i miei controlli (che io vorrei in modo più o meno vasto personalizzabili), la mia grafica, le mie componenti, non può essere strutturata nello stesso modo (una pagina aspx, cioè, padre, non visualizzata, "core", creata da me, e una pagina aspx "figlio", effettivamente visualizzata, che erediti dall'aspx padre e che sia estendibile ed personalizzabile).

Ho capito bene?

[WebMinus]

In rete ho trovato un post che credo sia piuttosto simile al mio.

Ciao a tutti. Mi trovo a dover realizzare un'applicazione web per un gruppo di aziende informatiche. Tale applicazione dovrà essere liberamente customizzabile dai vari partner per assolvere alle varie esigenze degli utenti finali. Il problema è quindi quello di definire l'architettura dell'applicazione in modo da garantirne la manutenibilità sia del modulo base che delle personalizzazioni. Se mi avessero chiesto un applicazione windows form, con Delphi saprei come fare. Delphi, ad esempio, consente di ereditare intere form e di agire sulla classe derivata. Ma in ambiente asp.net come si può fare? E' possibile ereditare una pagina aspx o un controllo web?

Purtroppo ha solo ricevuto questa risposta:

Non cambia nulla dal punto di vista OOP, quindi la risposta è sì. Esistono applicazioni di tipo CMS che fanno proprio questo

che non mi è molto di aiuto. Però anche qui accenna all'utilizzo di web control, come soluzione.

[WebMinus]

Scusate la ridondanza, ma quando trovo cose che potrebbero fare a caso mio le posto qui, per rendervi partecipi dei miei sforzi/progressi.

Ho visto che si può ereditare una pagina aspx da un'altra pagina aspx, "padre". Basta modificare, se mi è chiaro, l'ereditarietà della pagina aspx figlio, impostandola non su System.Web.UI.Page ma sulla mia pagina aspx padre. Quello che mi aspetterei facendo così però, e che non succede, sarebbe che tutto il contenuto dell'aspx padre fosse visualizzata al momento del lancio della pagina figlio. Invece mi resta una pagina vuota.

Funzionasse questo approccio credo potrebbe fare al caso mio, ma 1: non so se è possibile fare questa cosa, 2 nel caso non so come applicare i miei propositi.

[Stoicenko]

Non l'ho mai sperimentato ma credo che, così facendo, erediti solo la parte "server" della pagina e non la parte "client" (controlli asp.net e html).

Il processo che serve a te, secondo me, è quello che fa DotNetNuke CMS.

Le pagine sono solamente una collezione di "WebUserControl" (la storia è più complessa visto che in teoria sono più dei plugin che degli usercontrol).
In questo modo costringi i clienti ad usare gli usercontrol "as is" (cioè come li hai fatti tu), oppure a personalizzarseli estendendo le loro funzionalità.

Non credo esista un modo più furbo, infatti se un cms così "popolare" e "potente" come DotNetNuke ha utilizzato una modalità simile un perchè dovrà pur esserci no?

PS: ovviamente mi aspetto che tutti i tuoi controlli saranno inseriti in dll non editabili (ai fini degli aggiornamenti).

[WebMinus]

Ho provato a seguire quest'ultima strada, quella dei web user control.
Ho creato un primo web control che ho chiamato ControlloPadre. Dopodichè ne ho creato un'altro chiamato ControlloFiglio. In una pagina aspx chiamata PaginaConControlli ho poi trascinato il web control "ControlloFiglio".

Per definire l'ereditarietà tra controlli ho sostituito all'interno del ControlloPadre.ascx.cs

public partial class ControlloFiglio : System.Web.UI.UserControl

con

public partial class ControlloFiglio : ControlloPadre

Questo però non è sufficiente, immagino (visto che ancora non mi visualizza nulla) per rendere effettiva l'ereditarietà. Cos'altro dovrei fare per raggiungere il mio obiettivo?

[Stoicenko]

QUI c'è spiegato il perchè..

Ed è forse il motivo per cui DotNetNuke non usa direttamente usercontrol..

[Stoicenko]

In ogni caso, per mia esperienza personale, non vedo per quale motivo un cliente dovrebbe mettere mano al "core" di un applicativo. Semmai alle interfacce o, al limite, estendendo le funzionalità tramite plugin o moduli.

E' come se tu prendessi joomla, ti scarichi i sorgenti, modifichi un po' di cose e di incazzassi se non riesci ad aggiornarlo perchè perderesti le tue modifiche..

Le personalizzazioni dei clienti devono essere GIUSTAMENTE limitate proteggendo il core in dll non ricompilabili.

Se poi il cliente vuole una versione "sbloccata", gli aggiornamenti saranno fatti da loro tramite "merge" dei sorgenti.

[WebMinus]

Scusate il ritardo nella risposta:

Ho letto le riposte precedenti, ma se ho ben capito, il mio intento, quello di creare cioè una specie di livello superiore alla mia applicazione, una sorta di specchio della mia applicazione originale, visualizzazione compresa, non sarebbe comunque raggionto con le soluzioni proposte:

Facendo ereditare da una dll o da un user controll, piuttosto che da una pagina aspx, erediterei solamente la classe, senza la parte visuale.

Il punto è che questa applicazione non verrebbe distribuita direttamente ai clienti finali, ma a dei distributori del prodotto, che dovrebbero avere accesso al codice e che dovrebbero poter modificare il più liberamente possibile l'applicazione stessa. Tutto questo appunto senza limitare le eventuali operazioni di release.