DDL

Penso di non essere il solo ormai così abituato ad usare Entity Framework e LINQ da dimenticarmi i principi fondamentali tra su cui si basa Entity Framework finché non ci sbatto il muso…. Come oggi

Sto sviluppando la classica applicazioni di scambio dati tra sistemi legacy che fa un uso (ovviamente) importate dell’accessoacesso ai dati. Per cui cosa c’è di più comodo che un bel “reverse engineering” del database legacy per poi poterci operare con LINQ?

Tutto filava per il meglio con mia grande soddisfazione finché non si è presentato il caso di dover chiamare un applicativo esterno che era preposto a fare delle modifiche allo stesso database ma la cui logica era cablata nell’eseguibile e quindi “doveva essere usata così com’era”.

Vi riporto la parte di codice “incriminata”. Il programma reale è (ovviamente) un po’ più complesso e la logica è distribuita su più funzioni (altrimenti il problema mi sarebbe saltato subito all’occhio) ma rende l’idea del “pitfall” in cui si può cadere usando Entity Framework (o un qualsiasi altro ORM) come usiamo (o usavamo) ADO.NET.

N.d.R. “ShellandWait” è una funzione che si preoccupa di lanciare un programma con un parametro ed attenderne la chiusura e…. scusate la sintassi VB

Using ctx = provider.GetDataContext()
    Dim ordini = From p In ctx.PortafoglioOrdini
                 Where p.Ordine = ordine
                 Select p

    If ordini IsNot Nothing Then
        For Each ordine In ordini                    
            Dim res = ShellandWait(programmaEsterno, ordine.Riga)
        Next
    End If

    Dim ordineModificato = (From p In ctx.PortafoglioOrdini
                            Where p.Ordine = ordine
                            Select p).FirstOrDefault()
    
    Return (ordineModificato IsNot Nothing AndAlso ordineModificato.Stato = "X")
End Using

Diciamo (sempre per semplificare) che tra le varie cose che fa il programma esterno una di quelle è cambiare una colonna della tabella PortafoglioOrdini e io uso questa modifica per verificare che il programma abbia girato correttamente.

Ma il controllo mi tornava sempre false, benché la verifica sul database rendesse evidente che tutto funzionasse al meglio.

Quello che mi ero dimenticato è che il DbContext di Entity Framework implementa i pattern della Unit Of Work e Identity Map per cui una volta letti i dati non li rilegge più dal DB poiché, correttamente in quasi tutti i casi, ritiene di avere conoscenza dello stato letto e di tutte le modifiche apportate al dato che siano state persistite o meno.

Capito il problema (e per una volta senza ricorrere a Stack Overflow ) ho risolto facilmente il problema dividendo il singolo DbContext in due differenti, uno prima e uno dopo la chiamata al programma esterno.

Premessa: mi rendo conto che questo potrà apparire come un “piccolo spazio pubblicità”, ma in realtà è solo dettato da quell’entusiasmo che mi guida e sprona in questo bellissimo lavoro che ci accomuna. Chiarito questo…

Poco più di un annetto fa mi sono imbattuto in Command Query Resposability Segregation (CQRS) e Event Sourcing (ES). Non vi sto a dire che cosa sono perché se usate un qualsiasi motore di ricerca potete trovare migliaia di articoli in qualsiasi lingua che lo spiegano meglio di quanto potrei farlo io.

Devo ammettere che al primo impatto ho capito veramente poco e mi sono detto: “sarà la solita moda del momento che passerà in fretta”, ma qualche spunto e qualche post letto poi a casa mi avevano lasciato una certa curiosità di approfondire l’argomento. Per cui ho girato un po’ di conferenze in giro per l’Italia e alla fine ho capito le potenzialità dei due strumenti. Ve la faccio breve: se come me avevate visto le potenzialità di DDD ma avevate problemi a capire come calarle nelle vostre soluzioni, questi due strumenti possono essere una valida soluzione.

Non vi nascondo che essendo delle soluzioni architetturali “giovani” la loro implementazione non è proprio una passeggiata e per evitare di fare danni maggiori ai benefici e partire con il piede giusto  è necessario comprendere la filosofia che ci sta dietro. Ma le potenzialità sono enormi, specialmente se come capita a quasi a tutti (me compreso) una applicazione (o un insieme di applicazioni) continuano a crescere per anni rendendo complessa la loro gestione/manutenzione/crescita.

Se tutto questo vi suona famigliare, CQRS può essere una soluzione e ora non avete più scuse perché CQRS viene da voi… a breve, infatti, partirà un tour che coprirà gran parte dell’Italia proprio su CQRS e su an altro argomento caldo del momento: AngularJs e le applicazioni SPA.

Le tappe saranno Padova, Torino, Napoli e Bari, organizzate da Ynnova in collaborazione con Mauro Servienti di Managed Designs.

Per le informazioni dettagliate le trovate qui.

Ora non avete più scuse! ;)

Siete bravi sviluppatori Window Phone 8 e Windows 8? Questa challenge di Nokia DVLUP fa decisamente per voi!

Se sviluppate due nuove app per Windows Phone e due per Windows 8 guadagnate 800 XP che vi serviranno per i ricchi premi messi a disposizione da questo rewards program.

Ma non è finita qui: se ci mettete vicino un’altra app per ciascuna piattaforma (passando quindi a tre app per piattaforma) avrete in regalo un Lumia 925.

Sicuramente non è facile, visto il poco tempo a vostra disposizione, ma in questo caso lo sforzo vale sicuramente la candela!

E ricordatevi che avete a disposizione anche l’App Studio per aiutarvi in quest’ardua impresa.

Vi chiedo solo di impegnarvi a fare delle app di qualità e non solo orientate ad ottenere il premio… un po’ di #OrgoglioDev!!!!

In bocca al lupo!

Se usate Entity Framework e se, come me, allineate le piccole modifiche sul “dominio” con modifiche manuali sul DB (specialmente quando avete anni di dati dentro ), vi può capitare di ottenere il seguente errore:

Validation failed for one or more entities. See 'EntityValidationErrors' property for more details

A volte scoprire dov’è il problema di validazione non è così facile e può venire utile metterci un try-catch di questo tipo:

try
{
    ctx.SaveChanges();
}
catch (DbEntityValidationException e)
{
    foreach (var eve in e.EntityValidationErrors)
    {
        Debug.Print("Entity of type \"{0}\" in state \"{1}\" has the following validation errors:",
            eve.Entry.Entity.GetType().Name, eve.Entry.State);
        foreach (var ve in eve.ValidationErrors)
        {
            Debug.Print("- Property: \"{0}\", Error: \"{1}\"",
                ve.PropertyName, ve.ErrorMessage);
        }
    }
    throw;
}

Ovviamente grazie a Stackoverflow per la dritta

Certo, se usaste CQRS e I database documentali non avreste di questi problemi, ma questa è un’altra storia

Si… lo so… ormai il mondo dello sviluppo si muove su altre strade (ORM, CQRS, DB documentali), ma a volte abbiamo a che fare con il buon vecchio SQL.

Ogni volta che aggiungo una anagrafica dove prima c’era il “codice secco” non mi ricordo come aggironare in una sola volta tutti gli id della tabella…

…beh ecco un memo se siete come me

UPDATE b 
SET    b.article_id = a.id 
FROM   billofmaterials b 
       INNER JOIN articles a 
               ON b.articlecode = a.code 
WHERE  b.article_id IS NULL 

Ho ripreso in mano un progetto scritto sei anni fa. Devo dire che LINQ e gli Extension Methods sono dei gran strumenti.

        internal Dictionary<string, int> GetDictionaryCountries()
        {
            var retDict = new Dictionary<string, int>();
            using (ISession session = SessionHelper.GetSession())
            {
                IList<object> objList = session.CreateQuery("select i.Code, i.Id from Country i").List<object>();
                foreach (object obj in objList)
                {
                    Array arr = (Array)obj;
                    retDict.Add(Convert.ToString(arr.GetValue(0)), Convert.ToInt32(arr.GetValue(1)));
                }
            }
            return retDict;
        }

Diventa:

        internal Dictionary<string, int> GetDictionaryCountries()
        {
            using (ISession session = SessionHelper.GetSession())
            {
                return session.Query<Country>().Select(x => new { x.Code, x.Id }).ToDictionary(x => x.Code, x => x.Id);
            }
        }

P.S. la versione 1 era pure in VB.NET ma l’ho tradotta per un confronto più facile

P.P.S. Non sparate sul pianista sul perchè faccio una cosa del genere o quanto fa schifo tornare un dictionary, è stato il primo programma scritto in .NET

Questo è il primo di alcuni articoli che tratteranno l’utilizzo del framework Radical, sviluppato da Mauro Servienti.

Qualche premessa:

1. molto di quello che trovate qui lo potete trovare anche sulla documentazione di Radical che Mauro sta scrivendo, in inglese, impegni lavorativi permettendo;
2. lo scopo di questi post è presentarvi alcune facilities che questo framework mette a disposizione, in italiano! ;
3. io ho sempre trovato poco intuitivo l’utilizzo del toolkit MVVM Light Toolkit;
4. non mi piace molto l’utilizzo che fa Caliburn.Micro della proprietà Name dei controlli per il binding (mi hanno sempre detto: “in MVVM usare Name è MALE!” ), ma ammetto che è questione di gusti;
5. trovavo noioso e “error-prone” dover scrivere centinaia di righe di codice solo per gestire in maniera “decente” l’iterazione con l’utente.

Da queste poche righe, capite che fino a poco tempo fa il mio rapporto con MVVM e il databinding era molto problematico e  alla fine ricadevo sempre sulle care e vecchie Windows Forms che almeno mi consentivano un miglior controllo sull’iterazione con la UI.

In tutti i progetti di esempio, infatti, vengono dimostrati i vantaggi del data binding facendo vedere come, con due righe di codice, puoi recuperare i dati e visualizzarli, ma non fanno vedere che, una volta applicato il pattern MVVM, ci si scontra con molti altri problemi che non avevamo con le vecchie WinForms, ad esempio: la gestione delle finestre di dialogo dal ViewModel, il passaggio di parametri tra View (o ViewModel), fino ad arrivare al problema di dover gestire il data binding con controlli che non lo prevedono (PasswordBox)

Radical ha una risposta a tutti questi problemi ed a molti altri e vi semplificherà la vita e diminuendo del 50% il codice che state scrivendo se usate MVVM Light Toolkit (esperienza diretta su un mio progetto).

Partiamo da una guida in 8 passi per creare un progetto funzionate (in C#):

1. Create una nuova applicazione WPF;
2. Aggiungete, attraverso Nuget, un riferimento a  Radical.Windows.Presentation.CastleWindsor (ma se preferite o il vostro progetto usa già un altro IoC container sono supportati anche Unity2, Unity3, Autofac e Puzzle per le app RT). Nota: se non trovate il riferimento giusto dovete solo selezionare “Include Prelerase” nella ricerca dei pacchetti Nuget;
3. Cancellate la Window creata di default da Visual Studio (MainWindow.xaml);
4. Modificate il file "app.xaml" rimuovendo l'attributo "StartupUri"
5. Aggiungete un folder “Presentation” al progetto (è il folder dove Radical cerca di default le View e i ViewModel);
6. Create una nuova window chiamandola “MainView.xaml” (di default Radical considera Views le windows il cui nome finisce per “View”);
7. Create una nuova classe chiamandola “MainViewModel.cs” (di default Radical considera ViewModels le classi il cui nome finisce per “ViewModel” e le lega alla View che ha la stessa radice);

Andate nel file “app.xaml.cs” e aggiungete una singola riga di codice (ovviamente cambiando la dichiarazione del bootstrapper a seconda dell’IoC container scelto):

    public partial class App : Application
    {
        public App()
        {
            var bootstrapper = new WindsorApplicationBootstrapper<MainView>();
        }
    }

Premete F5 e tutto funzionerà, ossia si apre una Window vuota!

Come avrete capito anche Radical si basa sul paradigma Convention Over Configuration e dietro le quinte ha:

1. Legato la View e il ViewModel senza dover aggiungere alcunché;
2. Fatto partire la View da noi scelta (in questo caso la “MainView”);
3. Reso la MainView singleton (per convenzione se la View inizia per “Main” o “Shell” allora è singleton);
4. Abilitato molte altre cose che in progetto vuoto come questo non è possibile farvi vedere
5. Ovviamente tutte queste convenzioni possono essere “overridate” all’occorrenza

Ora abbiamo una Window vuota che dalla prossima volta vedremo di riempire con qualche controllo e un po’ di logica in modo da esplorare le altre potenzialità di questo framework.