Premessa / Digressione (che potete tranquillamente saltare...)
Sto realizzando una minuscola applicazione di prova per studiare ADO.NET (per poi passare a Linq). In breve si tratta di gestire un "Piano dei Conti" di una ipotetica applicazione di contabilità.
Per smanettare con ADO.NET, ho aggiunto al DataSet tipizzato che mi ha costruito il Wizard di VS 2008 due metodi (che non capisco perchè non vengano già costruiti dal Wizard...) per caricare e fare l'update di tutto il DataSet:
LoadData() chiama il metodo GetData() di ciascun TableAdapter tipizzato. A sua volta GetData() è un metodo (creato dal Wizard) che restituisce la tabella tipizzata corrispondente, dopo averla creata e averla "riempita" mediante il noto metodo Fill()
SaveData() utilizza invece un "nuovo" oggetto, il TableAdapterManager. Novità arrivata con VS 2008 (Occhio che TableAdapterManager non fa parte del Framework 3.5 o precedenti, ma viene creato dal Wizard) e leggete un po' cosa dice l'help:
The TableAdapterManager is a new component in Visual Studio 2008 that builds upon existing data features (typed datasets and TableAdapters) and provides the functionality to save data in related data tables. The TableAdapterManager uses the foreign-key relationships that relate data tables to determine the correct order to send the Inserts, Updates, and Deletes from a dataset to the database without violating the foreign-key constraints (referential integrity) in the database.
[...]
For example, consider an order entry application with which you can manage both new and existing customers and orders. If you have to delete an existing customer record, you must first delete all of that customer's orders. If you are adding a new customer record (with an order), you must first insert the new customer record before inserting that customer's orders because of the foreign key constraints that are in the tables.
La cosa che mi fa sorridere è che siamo dovuti arrivare al 2008 (!!!) per scoprire che era necessario un oggetto di questo tipo, per gestire gli update in modo un pochino più intelligente, senza obbligare i poveri sviluppatori a fare "plumbing code" o meglio fargli "odiare" ADO.NET e spingerli (giustamente) ad utilizzare strumenti ORM come NHibernate.
Fatta questa digressione, veniamo all'effettivo
Oggetto del post:
Dopo aver impostato il Debugger di Visual Studio a "non saltare" le righe di codice prodotte dal wizard, mi sono messo a pigiare il tasto F11 per guardare quel che succede "dietro le quinte" (lo so, sono curioso!), e mi è capitato di accorgermi di una cosa strana:
Avendo impostato un breakpoint all'interno del metodo SaveData(), com'è arcinoto spostando il mouse su "this" il debugger mi mostra il suo valore, come si vede nelle due immagini seguenti:
Poi facendo F11 il debugger mi porta nel sorgente GestionaleDataSet.Designer.cs (quello prodotto dal Wizard):
A questo punto, nel contesto dell'esecuzione, ovviamente "this" rappresenta l'oggetto di cui si sta eseguendo il metodo, come mostrato nella seguente immagine:
E fino a qui non ci piove. Ma ora arriva il bello. Con l'esecuzione stoppata sul metodo UpdateAll (come da immagine), mi sposto sulla pagina contenente il codice scritto da me, e risposto il mouse sopra "this", come prima.
Guardate cosa mi mostra il debugger:
Ma no! Anche se è assolutamente vero che "this" in questo momento effettivamente vale ciò che il debugger mi mostra, ma non è il valore del "this" che sto hooverando col mouse!
Che ne pensate?
posted @ sabato 15 marzo 2008 00:58