giovedì 2 luglio 2009
Come già anticipato in un mio precedente post, l’approccio basato su file XAML only per creare applicazioni con pattern MVVM che permettano una personalizzazione spinta dell’interfaccia, si scontra con l’impossibilità di inserire uno user control SENZA codebehind all’interno di una window (o di una page).
Tanto per intenderci, faccio un parallelo con ASP.net, essendo il concetto molto simile a quello che supporta i Web User Control (ascx).
In ASP.net ho una pagina, che contiene uno user control. Questo viene “registrato” in cima alla pagina con una “direttiva” del tipo:
1: <%@ Register TagPrefix="dnn" TagName="LANGUAGE" Src="~/Admin/Skins/Language.ascx" %>
2: ...
3: omissis
4: ...
5: <dnn:LANGUAGE runat="server" id="dnnLANGUAGE" showMenu="False" showLinks="True" />
In pratica, diciamo al compilatore di ASP.net: “quando compili la pagina, riferisciti a quel file sul disco e gestiscilo inserendo nella pagina il frammento di codice ASP.net che gli compete, agganciando tutti gli eventi nel code behind…”.
Questo concetto manca in WPF. Innanzitutto una precisazione è d’obbligo: gli UserControl sono praticamente identici ai controlli Utente Web, ma non possono essere usati senza avere una classe di code-behind compilata. Questo è dovuto al fatto che, per referenziare uno user control in una window o in una page, bisogna includere un riferimento all’assembly ed al namespace che lo contiene. Vediamo due snippets della pagina e dello User Control “Standard”:
1: <Window x:Class="WpfApplication1.Window1"
2: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
3: xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
4: xmlns:my="clr-namespace:WpfApplication1"
5: Title="Window1" Height="300" Width="300">
6: <Grid>
7: <my:StandardUC/>
8: </Grid>
9: </Window>
1: <UserControl x:Class="WpfApplication1.StandardUC"
2: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
3: xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
4: <StackPanel>
5: <TextBox x:Name="txtHello"></TextBox>
6: <Button x:Name="btnHello" Content="Click me!" Click="btnHello_Click"/>
7: </StackPanel>
8: </UserControl>
Quello che deve balzare agli occhi, è il riferimento xmlns:my=”clr-namespace:WpfApplication1” che indica dove trovare il controllo compilato, e non dice nulla riguardo alla parte XAML. Questo perchè in effetti, in fase di compilazione, la parte XAML viene tramutata in file .g (generated) e compilato come baml. A run time lo ritroveremo nel file .exe all’interno della sezione resources (Reflector rulez!)
Il punto è che, comunque, non c’è modo di specificare un riferimento ad un file fisico che verrà caricato dal disco a run-time. A questo punto sono d’obbligo un paio di citazioni: durante una chiacchierata virtuale con l’amico Andrea Boschin, e dopo aver parlato anche con il WPF-Guru Corrado Cavalli, è emersa una soluzione, che mi appresto a riportare.
Si tratta di creare una class CustomUserControl, la quale eredita da ContentControl, aggiungere una proprietà Source e sovrascrivere il metodo OnInitialize come si può vedere nel seguente snippet:
1: using System;
2: using System.Xml;
3: using System.Windows.Controls;
4: using System.Windows.Markup;
5:
6: namespace WpfApplication1
7: {
8: public class CustomUserControl : ContentControl
9: {
10: public string Source { get; set; }
11:
12: protected override void OnInitialized(EventArgs e)
13: {
14: base.OnInitialized(e);
15: XmlTextReader reader = new XmlTextReader(this.Source);
16: base.Content = XamlReader.Load(reader);
17: }
18: }
19: }
Ovviamente, questa diventa una specie di classe “base” per tutti i controlli Codebehind-less, per cui, quando li vorremo includere nella window dovremo fare come segue:
1: <Window x:Class="WpfApplication1.Window1"
2: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
3: xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
4: xmlns:my="clr-namespace:WpfApplication1"
5: Title="Window1" Height="300" Width="300">
6: <Grid>
7: <my:CustomUserControl Source="UserControl1.xaml"/>
8: </Grid>
9: </Window>
Ovvero utilizzare il riferimento al namespace che contiene la classe base, impiegare il controllo CustomUserControl ed impostare il file XAML da caricare a run-time.
In questo modo è stato superato il limite degli User Control in applicazione MVVM che mantengono le interfacce XAML esterne rispetto al compilato. Nel caso di MVVM gli UserControl con adeguati comandi di binding possono essere utilizzati come DataTemplate in controlli list (ListBox e affini). Ringrazio ancora Andrea e Corrado per il supporto e l’ispirazione… è sempre un piacere potersi confrontare con voi!
martedì 30 giugno 2009
Non è una novità, ma è sicuramente il desiderio espresso da molti dei nostri clienti: voglio un'applicazione che "cambi interfaccia" come io desidero.
Detta così sembra semplice, o comunque fattibile, e infatti in molti casi lo è: il web ci ha abituato bene, CSS, user controls, ASP.net sembrano fatti apposta per creare applicazioni "muta-forma".
Non si può dire altrettanto per i clients. Win32, con i suoi pregi e difetti, solo ultimamente ci ha messo a disposizione un blando supporto per i temi, che spesso si limitava a qualche ombra in più su un bottone o un effetto grafico su una lista.
Ritornando al desiderio del nostro cliente, il cambio di interfaccia non è solo un cambio di tema e/o colore, ma un vero e proprio cambio di struttura dell'interfaccia: stesse funzionalità in punti diversi e con approcci diversi o addirittura possibilità di rimuovere alcune funzionalità presenti in una versione "full" per semplificare delle versioni light della stessa applicazione.
Come può aiutarci nel perseguire questo obiettivo il pattern Model-View-ViewModel (sempre a braccetto con WPF, s'intende)?
Se pensiamo bene, WPF ci dà veramente tutto quello che ci serve per riuscire a caricare dinamicamente le interfacce. Per implementare la soluzione userò il MVVM Toolkit per
Visual Studio 2008, ma i ragionamenti sono piuttosto “trasversali” ed indipendenti dalla particolare implementazione di MVVM.
Gli obiettivi che ci prefiggiamo saranno i seguenti:
- Vogliamo avere una applicazione "completa" e funzionante priva di interfaccia grafica
- Le interfacce grafiche dovranno risiedere su disco e NON essere compilate
- Non dovranno esserci file di "code-behind" per le nostre interfacce, in quanto l'unica comunicazione con la logica avverrà attraverso databinding e commandbinding
Quindi, parlando in MVVM-lese, dovremmo produrre una dll (o un exe, nel nostro esempio) con all'interno i Model ed i ViewModel. Questi infatti definiscono completamente il dominio (Model) e l'operatività (ViewModel) della nostra applicazione.
Tutte le View dovranno essere esterne rispetto alla nostra applicazione, quindi saranno semplicemente una serie di file XAML. Questo è facilmente realizzabile in questo modo:
- Cancellare il file .cs (code behind) della nostra “View”
- Impostare la proprietà “Build Action” a “Content”
- Impostare la proprietà “Copy to output directory” a “Copy if newer”
Esiste un solo limite a questo approccio, peraltro superabile. Le nostre view non compilate non potranno contenere UserControls (sempre XAML only), in quanto il Framework non mette a disposizione un sistema per referenziare fisicamente i files che risiedono sul disco (un pò come faceva invece il prode ASP.net con i controlli .ascx).
Dopo aver creato il progettino, aggiungiamo un file .config, nel quale aggiungiamo la proprietà Theme, come si può vedere nel seguente snippet:
1: <?xml version="1.0" encoding="utf-8" ?>
2: <configuration>
3: <appSettings>
4: <!--Standard|Custom-->
5: <add key="Theme" value="Custom"/>
6: </appSettings>
7: </configuration>
Il parametro Theme, assieme alla classe ViewFactory che vediamo nel seguente snippet, decide come verranno create le nostre view, che sono l’unica cosa personalizzabile della nostra applicazione:
1: using System.Configuration;
2: using System.Windows;
3: using System.IO;
4: using System.Windows.Markup;
5:
6: namespace DynamicMVVM.Util
7: {
8: public class ViewFactory
9: {
10: public static System.Windows.Window CreateView(string viewName)
11: {
12: Window _view;
13: using (Stream _stream = File.OpenRead(string.Format("{0}/{1}.xaml",ConfigurationManager.AppSettings["Theme"], viewName)))
14: {
15: _view = (Window)XamlReader.Load(_stream);
16: }
17: return _view;
18: }
19: }
20: }
Con il metodo CreateView potremo creare “al volo” le view da passare come visualizzatori ai nostri ViewModels. Come possiamo vedere nel seguente frammento di codice, nell’evento di Startup della nostra applicazione, dopo aver creato il MainViewModel, utilizziamo il Factory delle View per creare la View sensibile alla configurazione:
1: using System.Windows;
2:
3: namespace DynamicMVVM
4: {
5: public partial class App : Application
6: {
7: private void OnStartup(object sender, StartupEventArgs e)
8: {
9: // Create the ViewModel and expose it using the View's DataContext
10: Window _view = Util.ViewFactory.CreateView("MainView");
11: _view.DataContext = new ViewModels.MainViewModel();
12: _view.Show();
13: }
14: }
15: }
A questo punto, il risultato si può vedere nella figura seguente; a sinistra la view “Standard” e a destra la view “Custom”:
E’ ovvio che questa non è una soluzione di Theming dell’applicazione, in quanto WPF offre già tutti gli strumenti per effettuare theming ad altissimo livello. Con questa soluzione possiamo effettivamente stravolgere le interfacce, impiegando addirittura controlli differenti. Come potrete notare, infatti, nella view “Custom” ho sostituito il controllo ListBox con un a ListView, spostato il pulsante e aggiunto un’immagine. Ovviamente sarebbe possibile fare molto di più, ma questo esempio vuole essere un pò la conclusione del mio post sulle cover dei cellulari e la loro similitudine con MVVM. E’ innegabile, infatti, che applicando questo pattern è possibile *REALMENTE* separare il comportamento dell’applicazione dal suo aspetto grafico, valicando il concetto di “Tema” fino ad arrivare ad una personalizzazione molto spinta. La chiave di lettura è ovviamente come sempre il Binding messo a disposizione da WPF che funge da collante tra le interfacce ed i ViewModels. Il codice è disponibile qui.
domenica 21 giugno 2009
Era ora! Ho trovato una piccola perla nel “mare magnum” dei videogiochi. Crazy Machines 2 è veramente fantastico. Semplice, giocabile, intrigante… l’ideale per chi ama un pò di sano ragionamento davanti ad un videogioco. Mi ha fatto rivivere i momenti con il vecchio Deflektor, o i pomeriggi con il “Big Domino Rally” (qualcuno se lo ricorda?)… In pratica, si tratta di completare dei “percorsi” combinando tra loro elementi quali discese, palle da bowling, laser che accendono candele, catapulte… e chi più ne ha più ne metta.
Tanto per darvi un’idea, un filmato che dà l’idea di quello che si è chiamati a realizzare nel videogioco…
Provate a giocarci… dà assuefazione!
domenica 14 giugno 2009
Sempre in tema di MVVM, continuo i miei pensieri sull’utilizzo di tale pattern. Dall’esperienza che ho accumulato in questi anni di lavoro, vi sono essenzialmente 2 tipi di applicazioni client:
- Le applicazioni “Labor Intensive”
- Le applicazioni “Casual Users”
Nel primo caso ci troviamo di fronte alle classiche applicazioni Windows Forms con treeview, griglie e controlli molto sofisticati. Sono spesso applicazioni scritte da tecnici per tecnici (non necessariamente da programmatori per programmatori, ma anche da programmatori per professionisti o per personale amministrativo); comunque solitamente si tratta di applicazioni dedicate al mondo dell’azienda, mondo in cui si dà per scontato che il personale possa trarre beneficio da interfacce più ricche e sofisticate.
Nel secondo caso ci troviamo di fronte al fenomeno rappresentato dal non sapere chi userà la nostra applicazione, la quale deve obbligatoriamente essere semplice da approcciare ed utilizzare. Dobbiamo in pratica abbassare il livello di complessità dell’applicazione, innalzando contemporaneamente il suo livello di usabilità. In pratica, l’applicazione deve essere “a prova di utente”. Questa caretteristica spesso viene ignorata, a favore di interfacce più ricche ma meno usabili.
In questo scenario, WPF e MVVM rappresentano veramente l’accoppiata vincente. WPF consente di modellare l’applicazione “Casual User” in modo che risulti accattivante e semplice da utilizzare. D’altro canto, MVVM consente di modellare le User Stories in modo estremamente lineare, in modo da arrivare al risultato di formare un vero e proprio percorso che guidi l’utente attraverso l’uso dell’applicazione stessa.
L’unico accorgimento che bisogna avere è il seguente: non bisogna utilizzare controlli “complessi”, ovvero tutta l’accessibilità deve essere “basic”:
- pressione di pulsanti
- selezioni da liste
- navigazione “wizard-style” tra pagine
Un esempio di eccellenza? Prendiamo la dashboard di XBox 360:
- è un’applicazione “Casual-User”;
- deve poter essere usata da tutti, anche da bimbi di 3 anni;
- Il controller permette di selezionare e muoversi attraverso liste e pulsanti;
- Ogni azione di selezione viene istanziata con il pulsante verde, mentre ogni azione di annullamento con il tasto rosso.
- Le azioni portano l’utente a percorrere una sequenza di “pagine” che lo guidano attraverso il percorso di selezione
- Dopo dieci minuti di utilizzo, chiunque sa impiegarla per arrivare ad ottenere il risultato desiderato
Concludo questa osservazione rimarcando il fatto che con MVVM si possono fare ANCHE applicazioni “labor intensive”… ma per le applicazioni “casual user” questo pattern non ha rivali, e l’accoppiata con WPF lo pone su di un livello di manutenibilità e produttività che con Win32 era praticamente inarrivabile.
domenica 7 giugno 2009
Eh sì, come titolo è parecchio strano, ma questo post mi frulla in testa da un pò di tempo e quindi volevo buttare giù delle idee/osservazioni che vengono dal mio attuale impiego di MVVM in una applicazione reale.
Il problema ricorrente, a mio avviso, nell’applicazione di pattern è la difficoltà che il neofita incontra nel “visualizzare” materialmente il pattern. E’ giusto che il pattern sia un’entità astratta, ma spesso può essere d’aiuto trovare delle similitudini che lo avvicinino al nostro vivere quotidiano. Con assoluta certezza, posso affermare che MVVM è “sul mercato” da moltissimo tempo, e lo si può trovare in moltissimi prodotti industriali. Alcuni esempi?
- I telefoni cellulari: alcuni modelli di telefoni cellulari (in passato soprattutto) sbandieravano la possibilità di “cambiare cover”. Se osserviamo questo caso possiamo individuare:
- View: la cover intercambiabile
- ViewModel: il display e la tastiera a membrana
- Model: la circuiteria integrata che fa funzionare effettivamente il telefono
La cosa interessante di questo caso è che se tolgo la cover, posso ancora usare il telefono (non è agevole come prima ma si può fare), proprio come succede con i test automatici. Inoltre, la circuiteria non sa nulla della cover, e potrebbe essere impiegata in altro modo, mentre la tastiera a membrana e il display sanno esattamente cosa visualizzare, e come azionare (Command) le funzioni del telefono. Tralasciamo l’analisi della batteria, che potrebbe essere vista come un servizio dalla circuiteria…
- Le automobili: in alcuni casi, le automobili vengono prodotte negli stessi stabilimenti, basandosi sugli stessi progetti ma impiegano marchi differenti. Un esempio reale è quello di una famosa casa tedesca che produce tra le altre le “macchine del popolo” (a buon intenditor…). In questo caso abbiamo un approccio un pochino più complesso:
- View: Carrozzeria, cruscotto, strumentazione, leva del cambio, rivestimento degli interni. Tutto ciò che il proprietario dell’automobile percepisce.
- ViewModel: tutti gli elementi che servono a trasferire comandi alla macchina in quanto “mezzo di trasporto”, o a visualizzare stati della macchina (centralina elettronica, cavi, ecc) scevri da marchi e/o aspetto esteriore. I View Model possono anche essere compositi, ovvero il cruscotto probabilmente può essere suddiviso in una serie di sotto-viewmodel (Tachimento, contachilometri, ecc) ciascuno responsabile di una parte dei dati trasmessi all’autista.
- Model: il telaio, il motore, la trasmissione ecc. In questo caso si potrebbe obiettare che il motore possa essere un servizio… così come l’impianto elettrico.
La cosa importante è che per questa casa di produzione la differenziazione dell’ ultimo strato del MVVM ha permesso di produrre macchine con diverso target economico, mantenendo in comune la produzione di gran parte degli elementi che compongono il Model ed il ViewModel della macchina stessa. Come a dire che l’apparenza ha la sua importanza :-)
Nel nostro settore, per quanto riguarda le applicazioni client, che sono quelle che il cliente “percepisce” può essere effettivamente raggiunto lo stesso livello di “disaccoppiamento” impiegando MVVM.
Personalmente, credo sia sempre interessante osservare come vengono prodotti industrialmente dei beni, perchè spesso la produzione stessa impiega pattern che noi informatici abbiamo formalizzato, ma che effettivamente fatichiamo ad impiegare.
domenica 10 maggio 2009
Il pattern MVVM mi piace perchè:
- è flessibile;
- permette di realizzare anche la parte “di interfaccia” delle nostre applicazioni in modo “predictable”
- si integra alla perfezione con WPF (e Silverlight).
A mio modesto parere, l’unico problema che ha è il suo nome, e per la precisione la parte ViewModel. Infatti quando si cerca di spiegarlo a dei colleghi che non ne hanno sentito parlare, magari durante dei corsi di formazione, si ha sempre un pò di imbarazzo a descrivere cos’è il ViewModel; soprattutto si fa fatica a comprendere che all’interno del ViewModel ci sono anche i comandi, ovvero il ViewModel diventa sì un contenitore di informazioni, ma espone anche dei metodi per interagire con le informazioni stesse o con altre parti di applicazione (basta pensare alla navigazione). Ora come ora, infatti, siamo ancora molto abituati a vedere il Data-Binding come applicabile solo alla parte Data, e non alla parte Command. Anche in questo caso, sarebbe bene non parlare più di DataBinding, bensì di Binding.
In effetti, a mio parere, un nome più intuitivo potrebbe essere Model-View-Interpreter. L’interpreter (ViewModel) effettivamente fa quello che un interprete linguistico fa tra due persone che non parlano la stessa lingua. I comandi sono le interazioni di una parte (view) con l’altra parte (Model); la parte in ascolto ovviamente può “rispondere” esponendo risultati (collections, oggetti) attraverso l’interprete, che si adopererà a fornirli alla parte View tramite il Binding. Si instaura quindi un vero e proprio dialogo tra il view ed il model a colpi di interazione tramite l’interprete.
Il bello di tutto ciò è che, se per un momento mettiamo da parte la view, ovvero la prima persona, e lavoriamo solo con l’interprete, possiamo “collaudare” la sua capacità di “interpretare” correttamente i comandi, ovvero effettuare Test Automatici.
Tra i vantaggi dell’impiego di MVVM (o MVI) possiamo quindi annoverare:
- Un robusto modello di applicazione
- Una netta suddivisione delle responsabilità di ogni parte di applicazione
- Una chiara modellazione di “chi fa che cosa” nell’applicazione
- L’impiego dei meccanismi di binding di WPF (o Silverlight)
- La possibilità di svincolare completamente il design dell’interfaccia (View) dall’effettiva azione dell’interfaccia (ViewModel)
- La testabilità delle azioni dell’interfaccia (ViewModel) in modo completamente indipendente dall’interfaccia (View)
Il meeting è andato… e c’è stata una buona affluenza di pubblico. Ci tenevo molto a ringraziare pubblicamente tutti i presenti, che con le loro domande e curiosità hanno contribuito a rendere il meeting veramente interessante. Per me è stato un onore poter proporre una soluzione che reputo molto interessante. Dai feedback che ho ricevuto alla fine del meeting, molti di voi proveranno .netTiers per vedere se può contribuire a rendere più snello e produttivo il lavoro di tutti i giorni, e questo ha sicuramente dato un senso al lavoro (ed alle nottate) profuse per la preparazione del meeting.
Da parte mia vi ringrazio di cuore ed aggiungo una cosa: ricordate sempre che XeDotNet siete voi, che con la vostra partecipazione ed entusiasmo fate sì che tutto questo sia possibile. Grazie!!
martedì 5 maggio 2009
Sempre in riferimento al meeting XEDotNet: NetTiers & CodeGeneration, che si terrà Venerdì 8 Maggio 2009 a Mestre presso l’Hotel Novotel, elenco alcuni dei pro e contro riscontrati durante l’utilizzo di .netTiers.
PRO:
- genera tutti i componenti DAL (provider e entities)
- genera tutte le relazioni tra entità (one-to-many, one-to-one, many-to-many)
- il codice generato è molto intuitivo (ovvero per caricare un cliente sarà stato generato il metodo GetCustomerById(), assieme a tutti i metodi per effettuare caricamenti per chiavi esterne ed indici). Tutti questi metodi permettono un accesso paginato ai dati.
- viene generato automaticamente anche uno strato di webServices e proxy che consentono di utilizzare il Framework anche in scenari 3-Tier
- supporta il DeepLoading/DeepSaving delle entità, ovvero specificando una entità e la lista delle entità relazionate, viene caricato sotto forma di oggetti e collections tutto il grafo degli oggetti collegati all'entità "radice". Tale entità potrà poi essere salvata unitamente a tutte le entità "figlie"
- le classi generate permettono l'utilizzo di campi BLOB
- i constraint del database sono incorporati nel codice, attraverso l'uso dei nullable types
- integrazione con Enterprise Library (2, 3, 3.1, 4), che significa poter usare i meccanismi di caching, exception handling ed instrumentation di Enterprise Library
- consente l'utilizzo di Stored Procedures Custom
- genera automaticamente una serie di Unit Test (compatibili con nUnit o Visual Studio) che permettono di testare tutto il Framework generato
- non utilizza librerie esterne, per cui qualunque aspetto è modificabile liberamente
- il codice generato è scalabile, si rifà alle Best Practices promosse da Microsoft ed è completamente basato su patterns
CONTRO:
- non supporta le tecnologie più recenti del Framework 3.5 (WCF, LINQ, EF)
- genera molto codice, per cui si può incorrere nel temuto "code bloat", ovvero la generazione di molto codice che non verrà di fatto mai utilizzato
- è necessario rigenerare il codice ad ogni modifica del database, anche se grazie all'uso delle partial classes le personalizzazione sulle entities e nelle altre classi non verranno sovrascritte
- le eventuali modifiche dei templates non sono semplici
Tutti i pro ed i contro riportati verranno ampiamente discussi nel meeting di venerdì, per cui se siete interessati ad approfondire questi aspetti, cosa aspettate a registrarvi? Vi aspetto!
lunedì 27 aprile 2009
Il giorno 8 Maggio 2009, alle ore 19.30, presso l’hotel Novotel di Mestre, XeDotNet presenta un meeting relativo alla Prototipazione rapida delle applicazioni software. Che cosa vi farò vedere in due ore di meeting? E’ presto detto: andremo ad esaminare le soluzioni di Generazione di Codice proposte dal template .netTiers, il quale permette la generazione automatica di intere applicazioni (Data Layer, Entity Layer, Service Layer, Web Application) in pochi minuti.
Spenderemo del tempo per capire in quali casi si possa applicare un approccio di questo tipo e se l’infrastruttura messa a disposizione da .netTiers sia sufficientemente flessibile o meno. Non mancheranno momenti di confronto con altre soluzioni che offrono risultati simili.
Tra gli argomenti che affronteremo:
- Database: from Tables to Entities
- Utilizzare validazioni su entità: codice autogenerato e possibilità di personalizzazione
- Integrazione con Enterprise Library
- Web Application Admin: come amministrare un database senza scrivere neppure una riga di codice
- .net Tiers applied: a real application
Quindi, 3 domande e 3 risposte, giusto per solleticare il vostro interesse:
D: perchè .netTiers potrebbe interessarmi?
R: perchè è un template open source per la generazione di codice, basato su patterns di largo uso e permette di velocizzare moltissimo il lavoro di realizzazione di applicazioni software.
D: Non voglio legarmi ad un prodotto che mi genera il codice, perchè il codice che viene generato non mi piace. .netTiers mi costringe ad usare il codice che genera?
R: Assolutamente no. Il codice generato è completamente personalizzabile prima della generazione (templates) e dopo la generazione (partial classes).
D: Ci sono altre soluzioni Microsoft (Entity Framework, Linq2SQL) che possono fare al caso mio. Cos’ha .netTiers più di queste?
R: Non parlerei effettivamente di caratteristiche in più o in meno. Semplicemente .netTiers offre il controllo sul codice generato (sia T-SQL che C#) e non genera codice SQL “al volo”. Viene evitato il temuto effetto “Black-Box”, ovvero la non conoscenza del codice ed il legame con codice al di fuori del nostro controllo. Inoltre c’è pieno supporto al database Oracle, caratteristica sicuramente interessante.
Se anche per voi economicità e robustezza delle soluzioni software sono due temi che vi stanno a cuore, non potete mancare! Per le iscrizioni, seguite questo link.
martedì 10 marzo 2009
Se avete voglia di sapere che cosa ha da offrire il nuovo sistema operativo Microsoft Windows 7 non potete mancare!
Il Windows 7 Installation Fest è un evento gratuito e aperto a tutti, dove potremo farci un'idea di tutte le caratteristiche e le nuove funzionalità di Windows 7.
Verranno illustrate le features del nuovo sistema operativo che ci permetteranno di essere più produttivi e di sfruttare al meglio l'hardware disponibile sul mercato.
Inoltre dopo l'overview, portando con sè un PC, sarà possibile installare la beta di Windows 7, per poter provare di persona la nuova Taskbar, la funzionalità delle Libraries, i nuovi Accessori e le moltissime altre funzionalità del nuovo sistema operativo.
Per garantire un rapido svolgimento delle installazioni si consiglia ai presenti di arrivare con la macchina pronta (formattata) o con Virtual PC già installato.
L'evento si terrà a Padova il 23/03/2009 alle ore 19.00, presso Start Cube - Incubatore Universitario d'Impresa - Via della Croce Rossa, 112 - 35129 PADOVA
Per iscrivervi, seguite il link: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032408092&Culture=it-IT