Il capitolo 12 affronta l’accesso ai dati ed i web services (sia SOAP style che REST).
I post precedenti sono: ASP.NET, system administration, WPF, protocolli e metaprogrammazione, testing, proprietà, dialog e Visual Studio, first class functions e xml, applicazioni e design pattern, oggetti .NET e IronPython, introduzione a Python, introduzione al libro e il preambolo.
L’esempio sviluppato dal libro in questo capitolo sfrutta ADO.NET, il database opensource PostgreSQL e il data provider Npgsql.
Personalmente mi sento di consigliarvi PostgreSQL che non ha nulla da invidiare a SQL Server e se lavorate con GIS è decisamente una figata. Quì dove lavoor io lo usiamo felicemente per applicazioni di produzione (usiamo anche SQL Server 2000, SQL Server 2005, SQLite e credo anche MySQL).
L’esempio è, prevedibilmente, un programma che sfrutta il provider per fare query, usare bind variables, transazioni e sfruttare i data adapters.
La parte sui web services invece comincia mostrando un esempio che consuma un feed Atom per poi buttarsi sul consumo di un servizio SOAP, MathService.
Sfrutta tool come wsdl.exe per creare una dll proxy del servizio remoto e la usa da Python normalmente:
>>> import clr
>>> clr.AddReference('MathService.dll')
>>> from MathService import MathService
>>> service = MathService()
>>> service.Add(3, 4)
7.0
Data la dinamicità di Python i proxy possono essere creati anche a runtime, ovviamente. Purtroppo però, dato che IronPython non supporta direttamente gli attributi, non è possibile creare un webservice SOAP.
Fortuna vuole che per REST e HTTP le cose siano più semplici. L’autore a questo punto sviluppa un intero servizio REST in IronPython per gestire delle note (composte da titolo, corpo e id). Sostanzialmente oltre ai vari verbi HTTP fa uso di WebRequest, HttpListener, HttpUtility e un po’ di XML.
Una delle applicazioni che abbiamo sviluppato è una web application che espone anche un REST web service consumabile in vari linguaggi in maniera molto intuitiva. Purtroppo, secondo la mia esperienza, devo dare ragione a chi si lamenta della poca interoperabilità di SOAP tra vari ambienti. Mi è capitato di sputare parecchio sangue per interfacciarmi a web service esposti da Java che si comportano in modo diverso da quelli SOAP esposti da .NET (direttamente da SQL Server).
Il capitolo 11 comincia con una introduzione ad ASP.NET per poi buttarsi nello sviluppo di un clone web dell’applicazione MultiDoc realizzata precedentemente sul framework Windows.Forms.
I post precedenti sono: system administration, WPF, protocolli e metaprogrammazione, testing, proprietà, dialog e Visual Studio, first class functions e xml, applicazioni e design pattern, oggetti .NET e IronPython, introduzione a Python, introduzione al libro e il preambolo.
Per usare IronPython con ASP.NET oltre Visual Web Developer Express o Visual Studio si ha bisogno anche di IronPython for ASP.NET disponibile sia per la versione classica (quella usata dal libro) che per la versione MVC di ASP.NET. I dettagli dell’integrazioen sono specificati in un apposito whitepaper: The New Dynamic Language Extensibility Model for ASP.NET.
La cosa interessante è che IronPython è perfettamente integrato nel debugger visuale, per cui non si perde niente in questa fase.
Dopo aver installato il pacchetto di integrazione il libro comincia a sviluppare l’applicazione MultiDoc sfruttando alcune feature, il Global.py, per avere a disposizione tutta la libreria standard di Python da ASP.NET.
Il primo esempio è sostanzialmente un excursus su controlli quali il Repeater ed eventi come Page_Load e Page_Prender.
Dopo aver introdotto il concetto di viewstate fa notare come la personalizzazione della serializzazione dello stesso non sia disponibile direttamente da IronPython. In pratica SaveViewState e LoadViewState non sono direttamente accessibili, alché usa una classe C# (evviva l’ambiente multi linguaggio!) per ovviare al problema.
In seguito, necessitando di serializzare oggetti Python, evidenzia come questi ultimi non siano direttamente gestibili dalla machinery del viewstate. Il trucco sta nell’usare la classe System.Web.UI.Pair e la serializzazione Python (pickling) abbinando i due nello stato del viewstate. Un trucco davvero carino, perché in tal modo si può serializare qualunque cosa ;-)
Il capitolo termina con la trasformazione della parte di editing dei MultiDoc in uno user control di ASP.NET.
L’autore fa notare come l’integrazione non sia appunto ancora totale, speriamo in futuro.