VSTS non supporta Architetture Mobile ?
Vero ! Se intendiamo Progetti EXE/DLL che girano su device; diverso (e non in questo post) il ragionamento su applicazioni ASP.NET 2.0 Mobile per cui si applicano invece tutte le caratteristiche di VSTS per progetti ASP.NET 2.0.
1) I designer (Application Diagram, Logical DataCenter Diagram e di conseguenza Deployment Diagram) non hanno SDM specifici per client mobile e per device
2) Unit Testing impossibile su progetti mobile: il progetto di avvio degli Unit Test può essere solo un progetto Windows
3) Performance Session impossibili su progetti mobile: non è in grado di avviare un test (sampling, instrumentation) su un progetto mobile perchè non è in grado di girare su device
4) Code Coverage impossibile su progetti mobile: vedi sopra
Tra l'altro, più in generale, Team System non supporta progetti di tipo class library: da luglio 2005 utilizzo un workaround che dopo quasi 6 mesi mi sembra funzionare bene (mi ci trovo bene insomma) in attesa di una prossima versione che supporti progetti class library e progetti mobile.
Vi propongo la mia soluzione:
1) Nell'application diagram utilizzo un'applicazione Windows per definire l'exe: non implementandolo ovviamente altrimenti otteniamo un progetto windows :-)
Per i database SDF utilizzo un database normale come se niente fosse: non serve a molto ma fa capire meglio l'architettura generale. Ad esempio: http://thinkmobile.it/photos/application_diagram/images/4842/original.aspx
2) Nel Logical DataCenter Designer utilizzo un Windows Client per rappresentare il device con una connessione verso se stesso per bindare le connessione alle DLL dall'eseguibile. Ad esempio: http://thinkmobile.it/photos/application_diagram/images/4853/original.aspx: la connessione verso il device è rappresentata da DeviceClientComponentiEndPoint nella figura.
Ricordo :-) che nei miei progetti non scrivo mai più di una riga di codice negli eventi del form ma faccio tutto da una dll che gestisce l'interfaccia utente: chi è venuto a qualche nostra conferenza sa di cosa parlo. Dal 1997 consigliamo di sviluppare a componenti... che spesso ancora oggi sono validi e utilizzati.
3) Nel Deployment Diagram bindo l'exe e tutte le DLL relative sul Device che è rappresentato da un client windows. Il database viene legato comunque a un "database server" che rappresenta solo e esclusivamente l'sdf. Le connessioni da exe a dll e fra dll si legano alla connessione che nell'LDD punta verso lo stesso client.
Risolte le limitazioni dei designer, veniamo al vero problema: supporto per Unit Test, Performance Session, Stress Test
Una volta generata la struttura della soluzione mobile creo un progetto class library windows per ogni class library mobile che si chiama come il progetto mobile con il suffisso DeskTop. Ad esempio se la struttura della soluzione mobile è la seguente http://thinkmobile.it/photos/application_diagram/picture5081.aspx creo un progetto windows class library DevLeap.SQL2005MobilePerformance.Mobile.BIZ.DeskTop in cui link tutti i sorgenti del relativo progetto mobile. A questo punto è possibile creare Unit Test su tutti i metodi delle classi del progetto Biz.Desktop per eseguire appunto Unit Test su di essi. Visto che i sorgenti sono linkati, se durante il test riscontro errori posso correggere il codice del progetto BIZ.Desktop e ritestare: visto che il codice sorgente è linkato da Visual Studio sto correggendo in realtà anche il progetto mobile. Fregato VS 2005, risultato ottenuto con poco sforzo e senza dispersione dei sorgenti :-)
Stesso ragionamento applicato per le performance session: in questo caso sono validi tutti i dati sulle chiamate alle funzioni, sul call stack, sui tempi di eseguzione (da prendere in modo RELATIVO visto che girano sul desktop): ottimo per eseguire un test esattamente come si farebbe per applicazioni desktop. Ovviamente i dati su Garbage Collection e similari non vanno considerati visto che sul device saranno completamente diversi: ad esempio il .NET CF 2.0 esegue un GC se l'applicazione supera 1 Mb di RAM...cosa che sul desktop non è detto che succeda :-)
Visto che uno Unit Test può portarsi dietro i risultati del Code Coverage, il problema è risolto con questa semplice tecnica :-)
"Discorso diverso" si applica al test sull'accesso ai dati visto che sul device utilizzeremo un SDF...mentre sul desktop...un SDF lo stesso !
Per usare un SDF sul desktop seguite le mie indicazioni sul post di luglio 2005 che riporto per completezza:
Seguire queste operazioni semplici operazioni: portare nella bin questi file
sqlceme30.dll
sqlceoledb30.dll
sqlceqp30.dll
sqlcese30.dll
sqlceca30.dll
sqlcecompact30.dll
sqlceer30en.dll
System.Data.SqlServerCe.dll
Fare una reference all'ultima (facendo browse e prendendola dalla tua cartella bin e non da quella di VS 2005) e poi usa normalemente SQL 2005 Mobile sia per accesso locale che per replica.
Ma dai....il gioco è veramente fatto: abbiamo tutti gli elementi per lavorare con VSTS eliminando tutte le limitazioni della prima versione di un prodotto che a mio avviso è spettacolare così com'è !
Ricordarsi di non prendere i dati di performance in modo assoluto ma sempre in modo relativo da test a test e che da uno Unit Test si può creare uno Stress Test sul desktop, molto più comodo che usare Hopper fin dalle prime implementaioni del progetto mobile.
Hope useful.