Select su DB verso ObservableCollection

Question

Buongiorno a tutti.

Forse ho già chiesto questa cosa.. ma non ne trovo traccia..e come l'ho  fatto fin'ora non mi piace.

Ambito : Entity Framework Code-First.

con questo codice faccio una select sul DB e carico il risultato in una property di tipo ObservableCollection<Soggetto> in una classe ViewModel.

  using (var db = new MyDBContext(CnStr))
                {
                    var sogg = from c in db.EFSoggetti select c;
                    SoggettiXScadenzario = new ObservableCollection<EFSoggetto>(sogg.ToList());                  
                }

Questa ObservableCollection è bindata su una ComboBox e quindi vengono utilizzati solo due campi della tabella (che su SQL ha 25 campi). Quindi dalla select mi serve solo "RagioneSociale" e "IDSoggetto".

se la variabile "sogg" la carico con i soli due campi che mi servono o come serve a me, con l'aggiunta di alcuni filtri (Where) non posso più fare caricare "SoggettiXScadenzario" ma devo fare un ciclo per tutta la collezione "sogg" e caricare la property SoggettiXScadenzario.

c'è un modo per evitare il ciclo? non so.. ma ho l'impressione che il ciclo mi rallenti.

Grazie.

---

Pranzo Stefano

Answer 1

Poiché ObservableCollection è un tipo generico, il risultato della tua query EF non può essere un anonymous type, altrimenti non sapresti quale tipo attribuire alla collezione.

Devi definire un oggetto che contiene solo le proprietà che ti interessano, quindi modificare la query EF perché crei istanze di quel tipo:

var sogg = ... select new TuoTipo { ... };

Nelle parentesi graffe devi inserire l'inizializzazione delle prorpietà della tua classe utilizzando le corrispondenti proprietà di c.

Così facendo, potrai usare TuoTipo come tipo per la ObservableCollection.

---

Marco Minerva [MCPD]
Blog: http://blogs.ugidotnet.org/marcom
Twitter: @marcominerva

Answer 2

Grazie Marco.

ho fatto una classe "SoggettoXComboBox e poi ho fatto questo:

SoggettiXScadenzarioForComboBox.Clear();
                using (var db = new GestionallDBContext(CnStr))
                {
                    var sogg = from c in db.EFSoggetti where c.Obsoleto != true select new SoggettoXComboBox { IDSoggetto = c.IDSoggetto, RagioneSociale = c.RagioneSociale};
                    SoggettiXScadenzarioForComboBox = new ObservableCollection<SoggettoXComboBox>(sogg.ToList());           
                }

è un poco una scocciatura che devi farti una classe "Custom".. ma tanto..usandola ovunque, è ottima. Magari si crea una procudura che all'avvio dell'applicazione, carica i dati e vengono usati in tutta l'applicazione.

Grazie ancora.

---

Pranzo Stefano

Answer 3

Non c'è di che, è sempre un piacere.

Grazie a te per aver condiviso la tua soluzione finale.

---

Marco Minerva [MCPD]
Blog: http://blogs.ugidotnet.org/marcom
Twitter: @marcominerva

Answer 4

Grazie Marco.

ho fatto una classe "SoggettoXComboBox e poi ho fatto questo:

SoggettiXScadenzarioForComboBox.Clear();
                using (var db = new GestionallDBContext(CnStr))
                {
                    var sogg = from c in db.EFSoggetti where c.Obsoleto != true select new SoggettoXComboBox { IDSoggetto = c.IDSoggetto, RagioneSociale = c.RagioneSociale};
                    SoggettiXScadenzarioForComboBox = new ObservableCollection<SoggettoXComboBox>(sogg.ToList());           
                }

è un poco una scocciatura che devi farti una classe "Custom".. ma tanto..usandola ovunque, è ottima. Magari si crea una procudura che all'avvio dell'applicazione, carica i dati e vengono usati in tutta l'applicazione.

Grazie ancora.

---

Pranzo Stefano

Ciao, scusate se mi intrometto, so che Marco è molto esperto, quindi a questo punto anzichè darti una possibile soluzione come stavo per fare, faccio una ulteriore domanda, ovvero : Come mai una soluzione come quella che ti sto per proporre non ti è stata proposta? ha qualche controindicazione? eccola :

ObservableCollection<dynamic> SoggettiXScadenzarioForComboBox;

                ///*******************

                using (var db = new GestionallDBContext(CnStr))
                {
                   SoggettiXScadenzarioForComboBox = new ObservableCollection<dynamic>(
                        db.EFSoggetti.Where(m => !m.Obsoleto)
                        .Select(c => new 
                        {
                            IDSoggetto = c.IDSoggetto, 
                            RagioneSociale = c.RagioneSociale 
                        }));
                }
                var test = SoggettiXScadenzarioForComboBox.First();
                int test2 = test.IDSoggetto;

Marco, grazie in anticipo se vorrai rispondere anche tu.

Answer 5

Innanzi tutto, non è vero che sono molto esperto, ma grazie per il complimento :-)

Vedo che la tua soluzione fa uso di dynamic. Come puoi leggere qui: http://msdn.microsoft.com/it-it/library/dd264741.aspx, questo operatore permette di evitare il checking dei tipi a compile time, poiché tutti i riferimenti sono risolti a tempo di esecuzione. Il suo tipico uso è con in accoppiata alle COM API, come quelle di Office, oppure con linguaggi dinamici come IronPython: http://msdn.microsoft.com/en-us/library/dd233052.aspx.

Il fatto che i tipi siano risolti a tempo di esecuzione, significa che il compilatore non ci può dare alcun aiuto verificando se stiamo utilizzando metodi e proprietà che effettivamente sono disponibili sull'oggetto: in pratica, non abbiamo nessun supporto dell'IntelliSense e nessun errore in fase di compilazione: tutti gli errori derivanti dall'uso non corretto di un oggetto dynamic si otterranno solo in fase di esecuzione, rendendo quindi il codice molto più difficile da gestire e manutenere.

Di conseguenza, dove possibile è sempre meglio usare classi concrete dichiarate nel codice, per sfruttare tutti i vantaggi derivanti dal compile-time type checking.

Ma c'è anche un altro motivo, molto più pratico. Visto che Stefano ha bisogno di una ObservableCollection, verosimilmente gli oggetti al suo interno dovranno implementare l'interfaccia INotifyPropertyChanged, per poter effettuare notifiche al cambiamento dei propri valori. Usando oggetti dinamici, questo non è possibile.

---

Marco Minerva [MCPD]
Blog: http://blogs.ugidotnet.org/marcom
Twitter: @marcominerva

Answer 6

Innanzi tutto, non è vero che sono molto esperto, ma grazie per il complimento :-)

Vedo che la tua soluzione fa uso di dynamic. Come puoi leggere qui: http://msdn.microsoft.com/it-it/library/dd264741.aspx, questo operatore permette di evitare il checking dei tipi a compile time, poiché tutti i riferimenti sono risolti a tempo di esecuzione. Il suo tipico uso è con in accoppiata alle COM API, come quelle di Office, oppure con linguaggi dinamici come IronPython: http://msdn.microsoft.com/en-us/library/dd233052.aspx.

Il fatto che i tipi siano risolti a tempo di esecuzione, significa che il compilatore non ci può dare alcun aiuto verificando se stiamo utilizzando metodi e proprietà che effettivamente sono disponibili sull'oggetto: in pratica, non abbiamo nessun supporto dell'IntelliSense e nessun errore in fase di compilazione: tutti gli errori derivanti dall'uso non corretto di un oggetto dynamic si otterranno solo in fase di esecuzione, rendendo quindi il codice molto più difficile da gestire e manutenere.

Di conseguenza, dove possibile è sempre meglio usare classi concrete dichiarate nel codice, per sfruttare tutti i vantaggi derivanti dal compile-time type checking.

Ma c'è anche un altro motivo, molto più pratico. Visto che Stefano ha bisogno di una ObservableCollection, verosimilmente gli oggetti al suo interno dovranno implementare l'interfaccia INotifyPropertyChanged, per poter effettuare notifiche al cambiamento dei propri valori. Usando oggetti dinamici, questo non è possibile.

---

Marco Minerva [MCPD]
Blog: http://blogs.ugidotnet.org/marcom
Twitter: @marcominerva

:) sai bene di essere esperto ! non era un complimento, ma una verità...

grazie della spiegazione, il secondo motivo mi pare più che valido, magari per il primo si ci può passare sopra...

Grazie ancora, a presto :)

Ciao.

Answer 7

Con "primo motivo" ti riferisci al fatto di non avere controllo dei tipi a tempo di compilazione?

---

Marco Minerva [MCPD]
Blog: http://blogs.ugidotnet.org/marcom
Twitter: @marcominerva

Answer 8

si, perchè? mi stai facendo venire dubbi :( cosa non so/non sto considerando?

sulla soluzione proposta da me non mi sono posto il problema dell'implementazione di INotifyPropertyChanged perchè comunque il nome mi ha fatto pensare che la destinazione del binding della collection fosse un combobox, che in genere è in sola lettura, ed eventualmente per aggiungere insiemi bisognerebbe passare da codice, quindi INotifyPropertyChanged sul tipo in effetti non mi sembrava fondamentale.

Grazie :)

Answer 9

Beh, tu riusciresti a programmare senza errori se, quando digiti il punto dopo il nome di una variabile, non ti apparisse l'elenco dei membri disponibili su quell'oggetto? Non hai mai un dubbio su quale è il nome corretto di un metodo?

Analogamente, se hai un oggetto dynamic, nel momento in cui tenti di richiamare un suo metodo, Visual Studio non potrà proporti l'elenco degli argomenti che si aspetta, quindi dovresti ricordarti tutte le signature a memoria.

Ti basta? :-D

---

Marco Minerva [MCPD]
Blog: http://blogs.ugidotnet.org/marcom
Twitter: @marcominerva

Answer 10

Beh, tu riusciresti a programmare senza errori se, quando digiti il punto dopo il nome di una variabile, non ti apparisse l'elenco dei membri disponibili su quell'oggetto? Non hai mai un dubbio su quale è il nome corretto di un metodo?

Analogamente, se hai un oggetto dynamic, nel momento in cui tenti di richiamare un suo metodo, Visual Studio non potrà proporti l'elenco degli argomenti che si aspetta, quindi dovresti ricordarti tutte le signature a memoria.

Ti basta? :-D

---

Marco Minerva [MCPD]
Blog: http://blogs.ugidotnet.org/marcom
Twitter: @marcominerva

Ciao Marco, scusami ero fuori.

Credo che tu abbia già compreso che ti stimo come programmatore, e che da te ho da imparare, ma onestamente se devo rispondere sinceramente alla tua domanda direi no, non mi basterebbe... (non prenderla come affronto! :) ) nel senso che non lo vedo un grande ostacolo se è solo per quello, d'altronde in questo caso vai a fare il binding che (o perlomeno fino a poco tempo fa) ti costringe a non usare l'IntelliSense nello xaml... quindi questa io personalmente non la vedo come limitazione. Però c'è da dire che non è fondamentale usare quel metodo che ho usato, anzi... sopratutto se si esce da questo contesto specifico per ovvie ragioni.

Tutto sommato, con la classe apposita, parliamo di poche righe aggiuntive nel codice che possono essere utili anche il altri casi, come ad esempio, come hai detto tu, in caso si voglia utilizzare l'implementazione di una qualsiasi interfaccia nella classe.

diciamo (secondo me) che in questo caso specifico, ovvero bindare dei dati in sola lettura utilizzando una classe per prenderne solo una parte... potrebbe essere "de gustibus", solo che pensavo ci fossero altri motivi (e magari ci sono) oltre quelli menzionati per non fare come ho fatto io.

Mentre secondo te (domanda) è da NON fare? oppure anche tu dici "de gustibus"?

Scusami se insisto ma per me il tuo parere comunque conta, ma voglio capire fino in fondo.

Ciao.

Answer 11

se devo rispondere sinceramente alla tua domanda direi no, non mi basterebbe... (non prenderla come affronto! :) )

Tranquillo, nessun affronto, anzi, mi piace molto discutere di queste cose :-)

Il fatto è che stai dicendo che il compile-time type checking, ovvero una delle feature fondamentali, alla base di linguaggi con Java, C# e VB .NET, osannata dal mondo intero, per te non è importante... Mi sembri quindi un po' strano che tu non ne apprezzi l'importanza.

Vorrei solo farti un piccolo esempio per farti capire quanto questa funzionalità sia importante. Dai un'occhiata a questo codice, un semplice Main di una Console Application:

static void Main(string[] args)
{
    dynamic a = "Ciao";

    if (a.Length == 0)
        Console.WriteLine("La stringa è vuota");
    else
    {
        if (a.Length > 4)
        {
            var c = a.substring(4, 1);
            Console.WriteLine("Il quinto carattere è: " + c);
        }
    }
}

La variabile a è di tipo dynamic, quindi l'applicazione viene compilata senza errori. D'altra parte, se la esegui, tutto funzionerà a dovere. Ora cambia il valore di a, ad esempio in "Marco". Poiché la lunghezza è maggiore di 4, verrà eseguita l'istruzione che estrae il quinto carattere. Tuttavia, il metodo substring è scritto male, perché ha l'iniziale maiuscola. Quindi, anche se l'applicazione viene compilata correttamente, in questo caso otterrai un errore in fase di esecuzione.

E questo è solo un esempio molto semplice, in cui effettivamente il problema si vede ad occhio nudo, ma prova a pensare a codice più complesso, in cui trovare problemi di questo tipo sarebbe molto più difficile, perché magari hai scritto un metodo con nome errato in un'istruzione che viene eseguita solo 1 volta su 100.

Oppure, supponi di avere questa classe:

public class Foo
{
    public void DummyMethod(int a, string b, string c, int d, char e)
    {

    }
}

Se tu la dichiari così:

dynamic foo = new Foo();

Nel momento in cui hai bisogno di invocare il metodo DummyMethod, devi ricordarti esattamente l'ordine, il numero e il tipo dei parametri, altrimenti otterrai nuovamente un errore in fase di esecuzione.

Insomma, mi sembra che motivi per cui il compile-time type checking è fondamentale ce ne siano: il compilatore ci garantisce, a tempo di compilazione, che nella nostra applicazione stiamo utilizzando il sistema dei tipi in modo corretto, controllando per noi gran parte degli errori che si possono commettere durante la scrittura di codice.

Fino adesso non ho volutamente fatto alcun discorso sulle performance, perché su questo ci sarebbe da aprire una capitolo a parte (cosa che, se ti interessa, possiamo fare molto volentieri). In generale, comunque, risolvere un tipo a tempo di esecuzione ha un costo dal punto di vista delle performance, costo che ovviamente non c'è se il tipo è stabilito in fase di compilazione: l'invocazione di un metodo dinamico è circa 10 volte più lenta dell'invocazione su un tipo concreto.

Naturalmente con questo non voglio dire che i tipi dinamici siano sempre da evitare. Io stesso li ho utilizzati diverse volte, e ci sono casi in cui il loro uso facilita molto lo sviluppo, come quando si lavora con COM Interop. Tuttavia, sono fermamente convinto che, se non estremamente necessario, sia meglio non ricorrere ad essi, per tutti i motivi che ti ho descritto.

---

Marco Minerva [MCPD]
Blog: http://blogs.ugidotnet.org/marcom
Twitter: @marcominerva

Answer 12

se devo rispondere sinceramente alla tua domanda direi no, non mi basterebbe... (non prenderla come affronto! :) )

Tranquillo, nessun affronto, anzi, mi piace molto discutere di queste cose :-)

Il fatto è che stai dicendo che il compile-time type checking, ovvero una delle feature fondamentali, alla base di linguaggi con Java, C# e VB .NET, osannata dal mondo intero, per te non è importante... Mi sembri quindi un po' strano che tu non ne apprezzi l'importanza.

Vorrei solo farti un piccolo esempio per farti capire quanto questa funzionalità sia importante. Dai un'occhiata a questo codice, un semplice Main di una Console Application:

static void Main(string[] args)
{
    dynamic a = "Ciao";

    if (a.Length == 0)
        Console.WriteLine("La stringa è vuota");
    else
    {
        if (a.Length > 4)
        {
            var c = a.substring(4, 1);
            Console.WriteLine("Il quinto carattere è: " + c);
        }
    }
}

La variabile a è di tipo dynamic, quindi l'applicazione viene compilata senza errori. D'altra parte, se la esegui, tutto funzionerà a dovere. Ora cambia il valore di a, ad esempio in "Marco". Poiché la lunghezza è maggiore di 4, verrà eseguita l'istruzione che estrae il quinto carattere. Tuttavia, il metodo substring è scritto male, perché ha l'iniziale maiuscola. Quindi, anche se l'applicazione viene compilata correttamente, in questo caso otterrai un errore in fase di esecuzione.

E questo è solo un esempio molto semplice, in cui effettivamente il problema si vede ad occhio nudo, ma prova a pensare a codice più complesso, in cui trovare problemi di questo tipo sarebbe molto più difficile, perché magari hai scritto un metodo con nome errato in un'istruzione che viene eseguita solo 1 volta su 100.

Oppure, supponi di avere questa classe:

public class Foo
{
    public void DummyMethod(int a, string b, string c, int d, char e)
    {

    }
}

Se tu la dichiari così:

dynamic foo = new Foo();

Nel momento in cui hai bisogno di invocare il metodo DummyMethod, devi ricordarti esattamente l'ordine, il numero e il tipo dei parametri, altrimenti otterrai nuovamente un errore in fase di esecuzione.

Insomma, mi sembra che motivi per cui il compile-time type checking è fondamentale ce ne siano: il compilatore ci garantisce, a tempo di compilazione, che nella nostra applicazione stiamo utilizzando il sistema dei tipi in modo corretto, controllando per noi gran parte degli errori che si possono commettere durante la scrittura di codice.

Fino adesso non ho volutamente fatto alcun discorso sulle performance, perché su questo ci sarebbe da aprire una capitolo a parte (cosa che, se ti interessa, possiamo fare molto volentieri). In generale, comunque, risolvere un tipo a tempo di esecuzione ha un costo dal punto di vista delle performance, costo che ovviamente non c'è se il tipo è stabilito in fase di compilazione: l'invocazione di un metodo dinamico è circa 10 volte più lenta dell'invocazione su un tipo concreto.

Naturalmente con questo non voglio dire che i tipi dinamici siano sempre da evitare. Io stesso li ho utilizzati diverse volte, e ci sono casi in cui il loro uso facilita molto lo sviluppo, come quando si lavora con COM Interop. Tuttavia, sono fermamente convinto che, se non estremamente necessario, sia meglio non ricorrere ad essi, per tutti i motivi che ti ho descritto.

---

Marco Minerva [MCPD]
Blog: http://blogs.ugidotnet.org/marcom
Twitter: @marcominerva

Ciao, sono contento che hai capito che non voglio fare lo sbruffone o il "troll", è una cosa che odio, ma spesso mi ritrovo a voler approfondire meglio i discorsi, e qualche volta capita che questo venga visto come "provocazione". :) Oltretutto anche per me è un piacere discutere di queste cose.

Non fraintendermi, non volevo dire che il compile-time type checking (non conoscevo nemmeno il termine ma so bene cosa si intende!) non sia utile, anzi, però nel caso specifico non mi sembrava poi di grande utilità, in quanto immaginavo uno scenario dove si doveva esporre in un viewModel una collection in sola lettura e per così dire "temporanea" da usare solo per fare il binding con una combobox, quindi diciamo che non avrebbe (sempre secondo il mio immaginario, poi non so se effettivamente sia così) avuto altri scopi. A questo punto, mi sembrava comodo non stare a scrivere una classe apposita solo per questo scopo. Poi ovvio, se devi usarla in diversi modi il discorso cambia. Dal mio punto di vista sarebbe come voler passare ad un metodo una struttura (scritta solo e appositamente per il passaggio dei dati) con due o tre proprietà al posto di passarle senza struttura, dirai : "ma qui è diverso...", ok, ma era solo per dire che per "poca cosa" il problema non si pone...

Naturalmente nemmeno io intendo dire che i dynamic siano sempre da utilizzare, anzi, come te preferisco avere i miei tipi ben definiti, ma nel caso specifico mi pareva utile, tutto qui, infondo non credo che si incorra in nessuno di questi problemi (o meglio non mi sembrano insormontabili, ma ripeto nel caso specifico, tranne... leggi più giù!) :) 

Detto questo, arriva la parte interessante : le performance! ecco un ottimo motivo :) ci volevo arrivare... Perchè? che succede dietro le quinte? in questo caso che perdita abbiamo?

se avessi ad esempio (lo so che è buuuu) una classe con decine di proprietà, e, come nel caso di Stefano dovessi bindarne (solo binding) solo la metà (ad esempio), e magari potresti pure dover mettere mano di frequente per cambiare qualcosa dopo (altro buuuu), scriveresti lo stesso la classe + l'istanza di linq apposita con tutte le proprietà, oppure ti risparmieresti almeno quella (la classe) a sfavore di compile-time type checking e velocità (quindi usando dynamic)? oppure useresti la reflection? ed eventualmente (altra cosa interessante) con la reflection, avendo comunque li stessi problemi con il compilatore, almeno sarebbe più veloce secondo te (rispetto al dynamic)? il numero delle proprietà contenute in esso è proporzionale alla perdita di performance?

Comunque, se andiamo a guardare bene ti potrei dare pienamente ragione quando dici :"..sono fermamente convinto che, se non estremamente necessario, sia meglio non ricorrere ad essi, per tutti i motivi che ti ho descritto." però allora aggiungerei pure "ovvero mai!" perchè in realtà non saranno mai strettamente necessari... abbiamo sempre fatto lo stesso senza di loro, quindi il confine tra necessario e non in realtà non esiste... se no ti direi pure : "allora anche in questo caso faciliterebbe lo sviluppo permettendo di evitare la scrittura di una classe apposita per uno scopo "così povero e semplice"".

Grazie.

Ciao.

Answer 13

Capisco quello che dici, ma tu stai facendo sempre il caso del bind con un ViewModel, io invece mi sono spinto un po' più in là facendo un discorso più generale, immaginando appunto uno scenario in cui non è necessario solo fare il bind, ma anche manipolare questi dati. E poi, partendo da qui, ho fatto una piccola disamina sui problemi che l'uso dei dynamic può determinare.

Per rispondere alla tua domanda, in quel caso creerei comunque una classe e la istanzierei con LINQ, innanzi tutto perché "guarderei al futuro": magari un domani avrò bisogno di fare elaborazioni su questa classe, di interagire con essa, quindi preferisco pensare fin dall'inizio di avere un oggetto concreto. Ovviamente questo è solo la mia opinione, è il mio modo di pensare. E poi, perché mi piacere sapere esattamente con quali oggetti lavoro :-)

D'altra parte, se la necessità è fare il bind di alcune proprietà, in sola lettura, allora la soluzione migliore è sicuramente quella di creare un anonymous type: in questo modo, non devo creare una classe apposita, ma nello stesso tempo ho tutti i benefici di un tipo determinato a tempo di compilazione.

Per quanto riguarda le performance, la reflection è ancora più lenta rispetto ai tipi dinamici. Puoi dare un'occhiata a questo post: http://theburningmonk.com/2010/09/performance-test-dynamic-method-invocation-in-csharp-4/ per un veloce test di prestazioni, che puoi replicare tu stesso. Un altro articolo interessante è questo: http://geekswithblogs.net/sdorman/archive/2008/11/16/c-4.0-dynamic-programming.aspx.

Infine, mi sono espresso male quando ho detto "strettamente necessario"... Perché, detto così, anche di LINQ si può fare tranquillamente a meno, ma spero di non doverlo fare mai :-) Diciamo che la cosa giusta da dire è che dynamic serve nei contesti in cui il suo utilizzo semplifica molto lo sviluppo. Ad esempio nel caso di COM Interoperability. Leggi questo articolo: http://msdn.microsoft.com/en-us/magazine/ff714583.aspx e in partcolare il paragrafo Working with COM Objects, per avere un'idea di cosa parlo.

C'è, però, uno scenario in cui è davvero strettamente necessario, ovvero quando si vuole interagire con linguaggi dinamici come IronPython. Dai un'occhiata a questo post per approfondire: http://blogs.msdn.com/b/charlie/archive/2009/10/25/hosting-ironpython-in-a-c-4-0-program.aspx.

---

Marco Minerva [MCPD]
Blog: http://blogs.ugidotnet.org/marcom
Twitter: @marcominerva

Answer 14

Ciao,

si, è vero, io facevo il discorso del caso specifico, ma ho apprezzato molto il discorso in generale che stavi facendo, che oltretutto, come già detto, in generale la penso come te. Infatti c'è stato un momento della discussione in cui stavo per postarti in risposta dei casi in cui dynamic sarebbe stato estremamente utile (casi che poi tu stesso hai postato successivamente nei link), ma ho pensato che la discussione sarebbe potuta diventare : "io difendo dynamic e tu invece..." quindi ho desistito anche perchè credo che sarebbe stato inutile, non era quello il concetto che volevo esprimere io, ed era chiaro che non lo fosse neanche per te (infatti poi hai postato i link :) )

In diversi casi, la questione, credo sia bene affrontarla in base a ciò che si vuole ottenere, anche se a volte dobbiamo rinunciare a qualcosa. Ad esempio se abbiamo bisogno di versatilità, usare dynamic e reflection non lo trovo scorretto, chiaro che poi ci sono le contro indicazioni, ma comunque sono delle opportunità che Microsoft ci offre, perchè non sfruttarle se servono. L'importante è esserne consapevoli, e in tal senso, credo che spingere la conversavzione sia stato molto utile.

Secondo me, in programmazione si possono fare mille discorsi tra cosa è meglio o cosa è giusto o sbagliato o bello o corretto ecc., ma alla fine della fiera, è il risultato che conta, ovvero quello che ho ottenuto è quello che mi aspettavo? esattamente quello che mi aspettavo? in tutti i sensi come mi aspettavo fosse? si?!? ok programma riuscito! e qui metterei il punto. Ma se noi programmatori ci limitassimo a fare programmi senza discutere un pò... beh ci saremo tolti la metà del divertimento!

Gazie per la discussione e per i link Marco, è stato un piacere.

A presto.

Answer 15

Esatto, alla fine l'importante è conoscere le varie alternative che si hanno a disposizione e scegliere attentamente quella che meglio si adatta alle nostre esigenze, valutando i trade-off di ogni soluzione.

Grazie a te, sono felice di aver discusso con te di questo argomento.

Alla prossima!

---

Marco Minerva [MCPD]
Blog: http://blogs.ugidotnet.org/marcom
Twitter: @marcominerva

Answer 16

Io so contento di aver imparato cose nuove..e del resto da voi si impara sempre cose nuove..e importanti..specialmente si imparano molto facilmente.

Grazie a tutti.

---

Pranzo Stefano

Answer 17

Io so contento di aver imparato cose nuove..e del resto da voi si impara sempre cose nuove..e importanti..specialmente si imparano molto facilmente.

Grazie a tutti.

---

Pranzo Stefano

Già, anche io :). Marco è sempre gentile e disponibile, oltre che molto preparato ovviamente.

@Marco

grazie.

Answer 18

Di nulla, è sempre un grande piacere.

---

Marco Minerva [MCPD]
Blog: http://blogs.ugidotnet.org/marcom
Twitter: @marcominerva