venerdì 25 maggio 2007

.NET remoting ed eventi

E' da un po' che mi scontro con il problema sintetizzato in oggetto: come sottoscrivere un evento tra due istanze che vivono in due appDomain differenti.
Il meccanismo base non è doverso da una sottoscrizione "normale" tra due istanze che vivono nello stesso appDomain, ma c'è un elemento chiave che DEVE rimanere in testa (ed è quello che invece non mi rimane in testa al momento opportuno): il Garbage Collector NON tiene conto (non riesce credo..) dei "link" via remote.
Poniamo quindi di avere un appDomain1 con una istanza1 e un appDomain2 con una istanza2.
i due appDomain sono ovviamente raggiungibili via remoting.
L'istanza1 crea un delegate ad un proprio metodo e lo sottoscrive ad un evento dell'istanza2.
private void Subscribe()
{
istanza2.RemoteEvent += new EventhHandler(mio_metodo);
}
Come si può vedere l'istanza1 non tiene traccia del delegate che viene creato all'interno del metodo.
Il GC nota che non c'è nessun link a tale delegate e quindi lo rimuove.
Il risultato di tutto questo è che l'istanza1 riceverà notifica dell'evento dall' istanza2 fintanto che il GC non scatta nell'appDomain1. Dopo di che nell'istanza2, all'atto di lanciare l'evento si genererà una eccezzione del tipo "SocketException".

La soluzione è semplice: basta mantere il delegate in memoria nella istanza1, come nell'esempio sotto, e il GC non ce lo cancellerà:

private EventHandler delegate1;
private void Subscribe()
{
delegate1 =
EventhHandler(mio_metodo);
istanza2.RemoteEvent += delegate1
}

Per evitare malintesi voglio sottolineare che questo metodo non è legato in alcun modo al metodo InitializeLifetimeService() da overridare.
QUesto metodo deve essere sovrascritto nelle classi che derivano da MarhalByRefObject facendo in modo che restituisca null se si vuole che il il tempo che tale classe rimarrà attiva in remoto sia infinito, ci.
Un tipico override è:

public override object InitializeLifetimeService()
{
return null;
}

lunedì 21 maggio 2007

Struttura base di una applicazione

Visto che è il mio primo post (sencondo in realtà ma il primo era solo di test) metto le mani ben avanti premettendo che non sono un esperto (sono uno di quelli che gli inglesi chiamano "wannabes") ma che da sempre mi sono sforzato per cercare di capire quale fosse la progettazione migliore per una applicazione generica. Con il termine "generica" voglio comprendere sia le win applications (ovvero che sono pensate e realizzate per girare un una macchina) che le web applications da accedere dal web, comprendendo anche tutte le sfumature intermedie.
La mia idea che si è formata nel tempo è alla fine molto semplice: alla base di tutto ci deve essere una buona struttura a livelli (la famosa struttura ISO/OSI non avevano sbagliato).
Una prima macro suddivisione è a tre livelli:
- La parte di interfaccia;
- la parte di "intelligenza" (business);
- la parte dei dati.

La cosa fondamentale è che ogni layer abbia una sula macro funzione specifica.

Questo potrebbe essere la descrizione verticale della nostra architettura; per fare in modo che il progretto sia realizzato bene e che non vi siano ripetizioni di codice (da evitare come la peste), bisogna individurare delle suddivisioni "logiche" del nostro codice.

Per fare ciò si deve giocare sia con la creazione di librerie che raggruppano tutta una serie di funzionalità e con i midificatori di visibilità che ogni linguaggio evoluto mette a disposizione (public/private/ etc.) con l'aggiunta di un itelligente uso della clausola static.

Questi sono le mie prime generice e superficiali considerazioni sull'argomento.
Visto che non mi considero mai arrivato, sono in costante ricerca di articoli che possano confermare, migliorare o smentire queste mie idee.
Ogni suggerimento / commeto è ben accetto.


sabato 19 maggio 2007

Primo post

Questo é il primo post. Da qualche parte si dovrà pure cominciare.