mercoledì 30 luglio 2008
Ci ho fatto caso proprio oggi :D
lunedì 30 giugno 2008
...mi sento di dover dire grazie a due persone. Veramente. Non ho parole. Mi avete reso veramente felice.
giovedì 8 maggio 2008
Da un paio di giorni è online il mio nuovo blog (in lingua inglese) all'indirizzo
http://www.codemetropolis.com
I contenuti saranno più o meno gli stessi di questo (NHibernate, LINQ, ASP.NET, WPF, and so on..), spero di riuscire ad aggiornarlo con una maggiore frequenza e continuità e di mettere a posto con il tempo la skin, che attualmente è ancora un po' grezzotta e manca addirittura del mio faccione! :-)
Per quanto riguarda il blog su UGI, ho intenzione di lasciarlo in vita, anche se gli argomenti saranno limitati a quanto concerne la community italiana.
Ciauz!
martedì 6 maggio 2008
Durante la realizzazione del layer di accesso ai dati di una semplice demo app, per il quale avevo scelto di utilizzare LINQ to Sql, sono incorso in un noioso bug nel recupero dei valori delle PrimaryKey, nel caso in cui questi siano autogenerati dal server di database.
Supponiamo di avere una tabella del tipo seguente, in cui la PK sia di tipo uniqueidentifier, automaticamente inizializzata per le nuove righe tramite la funzione di sistema newid():
Creiamo un nuovo DataContext di LINQ to Sql e importiamo al tabella creata; il designer crea una nuova entity con i campi omonimo delle colonne sul database:
Spesso, lato schema DB, i nomi delle chiavi contengono un riferimento alla tabella a cui appartengono. Per quanto riguarda le entità di dominio, invece, preferisco che gli identificativi si chiamino tutti allo stesso modo, sia per una questione di uniformità e leggibilità (non essendoci FK ma semplici riferimenti, non ho più la necessità di avere nomi diversi), sia perchè, ad esempio, potrei pensare di far implementare a tutte le mie entity un'interfaccia IHasIdentifier che esponga la proprietà Id e utilizzarla per implementare un GetById generico. Quindi, forte delle mie convinzioni, procedo alla modifica sulla entità di L2S generata dal designer:
Inoltre, mi ricordo anche di impostare, sulla property grid, che la proprietà Id è auto generata da DB e che deve essere recuperata dopo una query di Insert:
In fase di fetch, LINQ to Sql svolge egregiamente il suo lavoro, trasformando correttamente ogni condizione sulla proprietà Id in una where sulla colonna MySampleId:
Ciò purtroppo non accade quando, dopo una query di Insert, L2S tenta di recuperare il valore della chiave generata da database. Come si nota dalla query, infatti, viene erroneamente cercata una colonna chiamata Id, con successivo ed ovvio errore di Sql Server.
Ho segnalato il problema nei forum di MSDN, e mi è stato risposto che si tratta di un bug che verrà corretto con il rilascio del SP1. Attualmente ci sono solo due soluzioni:
- Utilizzare i medesimi nomi per proprietà e colonne
- Inizializzare manualmente la proprietà ad un nuovo Id sul costruttore della entity
Un'ultima curiosità: tutto ciò non si verifica nel caso in cui la PK sia un Identity e il motivo è che, in quel caso, Linq to Sql utilizza SELECT SCOPE_IDENTITY per recuperare il nuovo valore.
Technorati Tags:
LINQ to Sql
giovedì 17 aprile 2008
Lo dà il sito del New York Times: leggo un articolo, ma... "ehi, cosa vuol dire questo termine?"
Basta un doppio click per aprire un eccellente dizionario in popup.
Esempio
martedì 8 aprile 2008
Sul sito di Aspitalia.com è stato pubblicato un mio articolo sulla realizzazione di un custom extender in ASP.NET 3.5.
Con il bravo Riccardo abbiamo deciso di settarne il livello a 300 data la natura non proprio immediata, in ogni modo mi sono sforzato di rendere il tutto il più semplice possibile.
Colgo l'occasione di ringraziare tutto lo staff di Aspitalia per l'opportunità che mi è stata data.
Technorati Tags:
ASP.NET,
AJAX
martedì 5 febbraio 2008
Non mi stancherò mai di decantare la versatilità di NHibernate nel supportare domain model eterogenei. Esempio pratico: il nostro sito internet ha un sacco di pagine pressoché statiche, tipo il classico "Chi siamo", "Mission dell'Azienda", ecc.ecc.
Vogliamo permettere all'amministratore di inserire questi dati nel DB, ma vogliamo anche lasciarci la strada aperta ad aggiunte future, così se domani il cliente si sveglia e vuole anche una bella pagina con i contatti, possiamo aggiungerla senza modificare lo schema.
Un'idea può essere quella di contenere tutti questi dati all'interno di un bel Dictionary, ma come lo mappiamo con NHibernate?
Presto detto, basta utilizzare il tag <map> come segue:
1 <map name="CustomElements" generic="true" table="WebsiteCustomElements">
2 <key column="ParentId" />
3
4 <index column="ItemName" type="string" />
5 <element column="Value" type="string" length="3000" />
6 </map>
In questo modo NHibernate utilizzerà una tabella WebsiteCustomElements con le colonne ParentId, ItemName e Value per persistere il contenuto del nostro Dictionary.
Technorati tags:
NHibernate
giovedì 31 gennaio 2008
Premessa: ciò che scriverò è una banalità, ma secondo me in tanti non ne sono al corrente o non ci pensano. Di cosa parlo? Di cose del genere:
public const int MyConst = 10;
Il danno potenziale che le costanti pubbliche possono creare alla stabilità delle nostre applicazioni è enorme.
Why? Perché le costanti non sono altro che placeholder risolti in fase di compilazione. Questo vuol dire che, finché non si ricompila, il valore non viene aggiornato.
Implicazioni?
- Assembly A che definisce una costante MyConst = 10
- Assembly B che referenzia Assembly A e ne utilizza MyConst
- Assembly A cambia MyConst a 15
- Finché non ricompilo Assembly B, questo continua a vedere MyConst = 10
Ogni tanto mi capita di trovare righe di codice simili a quella in alto, con seguenti bug "strani" e dolori per scovarli. Ecco perché cerco sempre di abituare i junior che lavorano con me alla regola:
Le costanti devono essere sempre private o internal. Se serve esporle allora si utilizzino dei field readonly.
Augh!
martedì 22 gennaio 2008
Ho da poco iniziato a studiare ADO.NET Entity Framework e vorrei pubblicare impressioni, tip, ecc.ecc. man mano che imparo qualcosa.
Il primo passo per iniziare a lavorare con questo ORM di Microsoft è quello di fare qualche download, per cui oggi mi limiterò a fornire qualche link utile per utilizzare la beta 3 (in attesa della definitiva) su VS2008. La lista della spesa è più o meno questa, in ordine di installazione:
- ADO.NET Entity Framework Beta 3: qui
- Patch per installazione su VS2008 RTM: qui
- ADO.NET E.F. Tools (CTP di dicembre 2007): qui
- SQL Server 2005, c'è la Express Edition scaricabile qui
That's all...
Per iniziare a smanettare, consiglio di dare un'occhiata a questo (MOOOOOLTO SEMPLICE) quickstart e a questo progetto su Codeplex
Technorati tags:
Entity Framework
mercoledì 19 dicembre 2007
E bravo il nostro Simone! Dopo ScottGu (pardon, non ritrovo il link al volo), citato anche da Brad Abrams!!
Notevole.
Peccato che ultimamente si sia fissato con tutto ciò che è Apple!