Discussione 'MBV Objects'

MBV Objects

C'e' qualcuno che ha un esempio (codice) di un semplice Marshal by value Object con Remoting?

Sinceramente utilizzando la documentazione presente non ho trovato alcun esempio completo (come per il MBR, che invece gli esempio ce li ha)

Grazie a tutti

Re: MBV Objects

> C'e' qualcuno che ha un esempio (codice) di un semplice Marshal by value Object
> con Remoting?
>
> Sinceramente utilizzando la documentazione presente non ho trovato alcun
> esempio completo (come per il MBR, che invece gli esempio ce li ha)

Senza andare lontano c'è qui, su UGI!!!
http://www.ugidotnet.org/workshops/workshops_detail.aspx?ID=5b2c8d78-3654-48c1-a4a3-df0143018069
È il workshop di Aprile e trovi la mia sessione con slide ed esempi compresi, sia in C# che vb.net.
L'esempio 'console' è il più semplice e usa tutti i tipi di oggetti: MBV, CAO, SAO Singleton, SAO Singlecall.

Raffaele

Re: MBV Objects

Molto bello l'esempio che mi hai proposto....e veramente COMPLETO.

Grazie ciao!

Architetture possibili per la condivisione dei metadati

L'unica cosa che mi sfugge un po' e' il punto in cui nelle slide parli di Architetture possibili per la condivisione dei metadati, mi piacerebbe capire meglio il rapporto che ha con Remoting?

Ad esempio mi piacerebbe capire esattamente perche' dove parli di Interfacce i due metodi utilizzabili sono: Activator.GetObject o il factory pattern (che cmq. fa intuire qualcosa).

Inoltre riguardo alla CAS mi sembra di aver capito che con remoting ci sono dei problemi?

Re: Architetture possibili per la condivisione dei metadati

Rieccomi, scusa del delay ...

> L'unica cosa che mi sfugge un po' e' il punto in cui nelle slide parli di Architetture
> possibili per la condivisione dei metadati, mi piacerebbe capire meglio il rapporto che ha
> con Remoting?
Nella slide in cui introduco l'argomento, presento le varie alternative i cui pro e contro sono presenti nelle quattro successive.
In pratica è possibile seguire qualsiasi di quelle strade ma con vantaggi e svantaggi molto diversi.

Le prime volte che ho giocato con remoting volevo riuscire a rendere semplice l'istanziare con new un oggetto remoto. Dopo aver provato e capito i vari perchè mi sono reso conto che il gioco non ne vale la candela: ci sono troppi problemi che sono anche ben documentati nel libro e nelle FAQ di Ingo Rammer.

Ho anche provato, partendo dai sorgenti di remoting inclusi in rotor e confrontandoli con quelli veri del framework a capire se ci fossero alternative ma ho dovuto desistere perchè SoapSuds è una utility che in realtà non fa altro che chiamare dei metodi del framework e i suoi limiti richiederebbero la riscrittura di tanto tanto codice.


> Ad esempio mi piacerebbe capire esattamente perche' dove parli di Interfacce i due metodi
> utilizzabili sono: Activator.GetObject o il factory pattern (che cmq. fa intuire
> qualcosa).
In sostanza la soluzione che paga di più è quella del fatory pattern usando interfacce o classi astratte. Seguendo questa strada si perde l'automatismo dei file di configurazione che però si possono ricostruire 'manualmente' in modo molto semplice.
Seguendo questa strada ci sono poche righe di codice inerente l'infrastruttura di remoting e tutto il resto è molto semplice.
Se guardi i miei esempi sono fatti con questa logica.
L'unica alternativa a questo approccio è la condivisione dell'assembly server sul client cosa che raramente ha senso fare.

> Inoltre riguardo alla CAS mi sembra di aver capito che con remoting ci sono dei
> problemi?
Lo stack walk non passa i confini di remoting e quindi non puoi far conto sulla CAS per oggetti remoti. Ovviare non è complicatissimo ma devi pensarci tu.

Il successore di Remoting e Web services è Indigo di cui ancora si sa poco visto che ad Aprile, all'MVP Summit, a mia precisa domanda Don Box ha risposto che del codice che era stato presentato alla PDC (che è l'unico che circola ancora adesso) non c`è più nulla di valido. I concetti e l'architettura presentati alla PDC sono assolutamente corretti e invariati ma l'implementrazione che avevo cominciato a studiarmi non lo è più.
Ti dico questo perchè ha senso usare remoting e webservices per le cose che ci servono oggi, senza fare troppi progetti o investire troppo tempo/denaro nell'espandere l'infrastruttura attuale.
Usando in remoting la strategia del factory pattern si minimizza al massimo quello che sarà (per chi lo vorrà fare) il porting verso Indigo.

Raffaele

Re: Architetture possibili per la condivisione dei metadati

on 29. Aug 2004 21:31 Raffaele Rialdi wrote:
> Ti dico questo perchè ha senso usare remoting e webservices per le cose che ci servono oggi,
> senza fare troppi progetti o investire troppo tempo/denaro nell'espandere l'infrastruttura
> attuale.
> Usando in remoting la strategia del factory pattern si minimizza al massimo quello che sarà
> (per chi lo vorrà fare) il porting verso Indigo.
>
> Raffaele


Ti ringrazio ancora, terro' in seria considerazione le cose che mi hai detto!

Arturo