Il blog di Ugo Lattanzi | ASP.NET, MVC, .NET Framework, WCF, WF, NHibernate, Linq, Microsoft

Gestione dei DateTime ed i vari TimeZone

imperugo — Mon, 16 May 2011 15:50:00 GMT

Tra le varie problematiche che ho incontrato nello sviluppare Dexter, ce n’è una il cui rimedio è divenuto indispensabile nella maggior parte delle applicazioni, ossia una gestione un po’ più avanzata del DateTime all’interno dell’applicazione.
Durante la migrazione tra i vari server, ho riscontrato un problema con i vari DateTime di ciascuno di essi; essendo dislocati in aree geografiche diverse, restituivano infatti valori nettamente differenti per via del fuso orario dal server vecchio a quello nuovo.

Il primo server su cui risiedeva il mio blog era su un provider il cui fuso orario era impostato su EST, che differisce di tre ore rispetto all’orario del nuovo server che è impostato sulla PST. Questa differenza ha causato un’errata visualizzazione degli orari dei post sul mio blog, che risultavano sfalzati di tre ore

Oltre a sistemare tutti i valori memorizzati nel database con una query, ho deciso di affrontare e risolvere il problema in modo da non avere una dipendenza del fuso orario nelle date memorizzate, essendo quindi libero di gestire l’output dell’ora nel TimeZone a me più congeniale.

Per prima cosa ho realizzato uno UserType per NHibernate che convertisse tutte le date in ingresso verso il databse in formato UTC e, in fase di idratazione della entity, le convertisse nel TimeZone da me configurato. Questa operazione, in codice, si traduce più o meno così:

[Serializable]
internal class DateTimeUtc : IUserType {
    #region IUserType Members

    /// <summary>
    /// Determines whether the specified <see cref="System.Object"/> is equal to this instance.
    /// </summary>
    /// <param name="x">The <see cref="System.Object"/> to compare with this instance.</param>
    /// <param name="y">The y.</param>
    /// <returns>
    ///     <c>true</c> if the specified <see cref="System.Object"/> is equal to this instance; otherwise, <c>false</c>.
    /// </returns>
    public new bool Equals ( object x , object y ) {
        if ( ReferenceEquals ( x , y ) ) {
            return true;
        }
        if ( x == null || y == null ) {
            return false;
        }
        return x.Equals ( y );
    }

    /// <summary>
    /// Returns a hash code for this instance.
    /// </summary>
    /// <param name="x">The x.</param>
    /// <returns>
    /// A hash code for this instance, suitable for use in hashing algorithms and data structures like a hash table. 
    /// </returns>
    public int GetHashCode ( object x ) {
        return x == null
                   ? typeof ( DateTime ).GetHashCode ( ) + 473
                   : x.GetHashCode ( );
    }

    /// <summary>
    /// Retrieve an instance of the mapped class from a JDBC resultset.
    /// Implementors should handle possibility of null values.
    /// </summary>
    /// <param name="rs">a IDataReader</param>
    /// <param name="names">column names</param>
    /// <param name="owner">the containing entity</param>
    /// <returns></returns>
    /// <exception cref="T:NHibernate.HibernateException">HibernateException</exception>
    public object NullSafeGet ( IDataReader rs , string[] names , object owner ) {
        object obj = NHibernateUtil.DateTime.NullSafeGet ( rs , names[ 0 ] );
        if ( obj == null ) {
            return null;
        }

        var dbValue = ( DateTime ) obj;

        SiteConfiguration configuration = DexterContainer.Resolve <IConfigurationRepository> ( ).Configuration;

        dbValue = configuration != null
                      ? System.TimeZoneInfo.ConvertTimeFromUtc ( dbValue , configuration.TimeZone )
                      : dbValue.ToUniversalTime ( );

        return dbValue;
    }

    /// <summary>
    /// Write an instance of the mapped class to a prepared statement.
    /// Implementors should handle possibility of null values.
    /// A multi-column type should be written to parameters starting from index.
    /// </summary>
    /// <param name="cmd">a IDbCommand</param>
    /// <param name="value">the object to write</param>
    /// <param name="index">command parameter index</param>
    /// <exception cref="T:NHibernate.HibernateException">HibernateException</exception>
    public void NullSafeSet ( IDbCommand cmd , object value , int index ) {
        if ( value == null ) {
            ( ( IDataParameter ) cmd.Parameters[ index ] ).Value = DBNull.Value;
        }
        else {
            var myValue = ( DateTime ) value;

            SiteConfiguration configuration = DexterContainer.Resolve<IConfigurationRepository> ( ).Configuration;

            if ( configuration != null ) {
                myValue = myValue.Kind == DateTimeKind.Unspecified
                              ? System.TimeZoneInfo.ConvertTimeToUtc ( myValue , configuration.TimeZone )
                              : myValue.ToUniversalTime ( );
            }
            else {
                myValue.ToUniversalTime ( );
            }

            ( ( IDataParameter ) cmd.Parameters[ index ] ).Value = myValue;
        }
    }

    /// <summary>
    /// Return a deep copy of the persistent state, stopping at entities and at collections.
    /// </summary>
    /// <param name="value">generally a collection element or entity field</param>
    /// <returns>a copy</returns>
    public object DeepCopy ( object value ) {
        return value;
    }

    /// <summary>
    /// During merge, replace the existing (<paramref name="target"/>) value in the entity
    /// we are merging to with a new (<paramref name="original"/>) value from the detached
    /// entity we are merging. For immutable objects, or null values, it is safe to simply
    /// return the first parameter. For mutable objects, it is safe to return a copy of the
    /// first parameter. For objects with component values, it might make sense to
    /// recursively replace component values.
    /// </summary>
    /// <param name="original">the value from the detached entity being merged</param>
    /// <param name="target">the value in the managed entity</param>
    /// <param name="owner">the managed entity</param>
    /// <returns>the value to be merged</returns>
    public object Replace ( object original , object target , object owner ) {
        return original;
    }

    /// <summary>
    /// Reconstruct an object from the cacheable representation. At the very least this
    /// method should perform a deep copy if the type is mutable. (optional operation)
    /// </summary>
    /// <param name="cached">the object to be cached</param>
    /// <param name="owner">the owner of the cached object</param>
    /// <returns>
    /// a reconstructed object from the cachable representation
    /// </returns>
    public object Assemble ( object cached , object owner ) {
        return cached;
    }

    /// <summary>
    /// Transform the object into its cacheable representation. At the very least this
    /// method should perform a deep copy if the type is mutable. That may not be enough
    /// for some implementations, however; for example, associations must be cached as
    /// identifier values. (optional operation)
    /// </summary>
    /// <param name="value">the object to be cached</param>
    /// <returns>a cacheable representation of the object</returns>
    public object Disassemble ( object value ) {
        return value;
    }

    /// <summary>
    /// The SQL types for the columns mapped by this type.
    /// </summary>
    /// <value></value>
    public SqlType[] SqlTypes {
        get {
            return new[] {
                new SqlType ( DbType.DateTime )
            };
        }
    }

    /// <summary>
    /// The type returned by <c>NullSafeGet()</c>
    /// </summary>
    /// <value></value>
    public Type ReturnedType {
        get { return typeof ( DateTime ); }
    }

    /// <summary>
    /// Are objects of this type mutable?
    /// </summary>
    /// <value></value>
    public bool IsMutable {
        get { return false; }
    }

    #endregion
}

Una volta affrontato il problema del salvataggio della data, rimaneva soltanto quello riguardante i filtri delle query che, per i campi DateTime, dovevano effettuare una conversione in formato UTC più o meno in questo modo:

Purtroppo mi è capitato più volte di dimenticarmi di effettuare quel ToUniversalDateTime all’assegnazione del parametro di una query, con l’ovvio problema di avere risultati sballati in fase di visualizzazione.

Fortunatamente con la versione 3.2 di NHibernate è stato rivisto parzialmente il Driver di SqlServer, che ora espone un metodo "AdjustCommand” subito prima dell’ExecuteQuery. Il codice seguente mostra come effettuare automaticamente la conversione dal DateTimeKind.Local al DateTimeKind.Utc:

public class DexterSqlClientDriver : SqlClientDriver {
    
    public override void AdjustCommand ( System.Data.IDbCommand command ) {
        foreach (var parameter in command.Parameters.Cast<SqlParameter> ( ).Where ( x => x.SqlDbType == SqlDbType.DateTime && ( x.Value is DateTime ) )) {
            var dateTimeValue = (( DateTime )parameter.Value).ToUniversalTime (  );
            parameter.Value = dateTimeValue;
        }
    }
}

A questo punto, il codice di esecuzione della query si semplifica ancor di più poiché il developer non deve sapere, o ricordarsi, che il formato della data sul database è differente, in quanto la conversione avviene in automatico.
Il risultato è il seguente:

Comodo no?

ConfORM, NHibernate, Oracle e gli Integration Test

imperugo — Wed, 20 Apr 2011 15:45:00 GMT

In questi giorni sto lavorando parecchio ad un’applicazione che usa Oracle come repository e NHibernate come framework di persistenza. Essendo questa un’applicazione “delicata” ho necessità di creare una serie di integration test che mi “garantiscano” il corretto funzionamento, in modo da non avere spiacevoli sorprese in fase post deploy.

Letta così la questione non presenta particolari criticità, ma ho dovuto affrontare un nuovo scenario riguardante Oracle e la sua gestione degli indici.

Prima di entrare nel dettaglio tecnico vorrei puntualizzare che la soluzione da me adottata è la conseguenza di una totale inesperienza relativamente al mondo Oracle, potrebbe quindi esistere una strada migliore e più corretta per arrivare alla soluzione (magari se la conoscete, datemi qualche consiglio ).

Fatta tale premessa provo a descrivere un po’ lo scenario. Nella mia installazione interna all’azienda ho un solo database engine di Oracle che contiene al suo interno l’applicazione di sviluppo, quella di test ed infine quella di quality assurance. Quindi, lato database, ho tre schema/utenti ben differenti denominati rispettivamente Dev, Test e QA, ed ognuno di questi ha le proprie tabelle con i propri dati, come mostrato dalla tabella seguente:

dev	test	QA
dev.users	test.users	qa.users
dev.roles	test.roles	qa.roles
dev.usersinroles	test.usersinroles	qa.usersinroles

Essendo l’applicazione in uno stato di sviluppo più o meno avanzato, il database delle linea dev non subisce molti “restyling”, al contrario del database dei test che viene cancellato e ricreato ad ogni test.

Il mio problema è nato proprio durante la fase di “drop & create” dello schema: questo viene creato correttamente, ma poi la procedura di NHibernate non completa correttamente il tutto perché, al contrario di quanto avviene per le tabelle, gli indici non sono legati ad uno specifico schema, sollevandomi una brutta eccezione del tipo “nome oggetto già utilizzato” (riferendosi all’indice che si stava cercando di creare).
Se si riosserva la tabella riportata in precedenza si può facilmente intuire che l’univocità del nome della tabella è data dalla combinazione dello schema con il nome della tabella stessa. Purtroppo o per fortuna (direi più per fortuna) questa “combo” non esiste per gli indici, il che si traduce nel dover creare indici con nomi differenti per ogni “environment” in quanto trasversali all’interno del database engine.

L’indice IX_ItemType non è dev.IX_ItemType!

La mia configurazione di NHibernate creava automaticamente degli indici per alcuni scenari (nello specifico per il “Table Per Class Hierarchy”) in modo da aiutare il database nell’eseguire le query. Con il supporto del buon Fabio ho creato un Applier per ConfORM (in realtà ho fatto copia ed incolla di quello esistente) che mi permette di stabilire un prefisso per tutti gli indici, in modo da avere un risultato tipo il seguente:

IX_MyIndex;
IX_Test_MyIndex;
IX_QA_MyIndex;

Una volta creato l’applier mi è bastato effettuare una merge dello stesso e, come per magia, tutti i test sono diventati verdi.
Per chi fosse interessato posto il codice dell’applier di ConfORM

public class DiscriminatorIndexNameApplier : IPatternApplier<Type, IClassAttributesMapper> {
    private readonly IDomainInspector domainInspector;
    readonly string indexPrefix;

    public DiscriminatorIndexNameApplier ( IDomainInspector domainInspector, string indexPrefix ) {
        this.domainInspector = domainInspector;
        this.indexPrefix = indexPrefix;
    }

    #region IPatternApplier<Type,IClassAttributesMapper> Members

    public bool Match ( Type subject ) {
        return domainInspector.IsTablePerClassHierarchy ( subject );
    }

    public void Apply ( Type subject, IClassAttributesMapper applyTo ) {
        applyTo.Discriminator ( dm => dm.Column ( cm => cm.Index ( indexPrefix + subject.Name + "EntityType" ) ) );
    }

    #endregion
}

e per il suo utilizzo:

IPatternsAppliersHolder patternsAppliers = ( new ImperugoPatternsAppliersHolder ( orm , NHConfiguration.Instance.IndexPrefix ) )
    .Merge ( new ConfORM.DiscriminatorValueAsEnumValuePack <Person, PersonDiscriminatorMap> ( orm ) )
    .Merge ( new ConfORM.DiscriminatorValueAsEnumValuePack <View , ViewDiscriminatorMap> ( orm ))
    .Merge ( new ConfORM.DiscriminatorIndexNameApplier ( orm, NHConfiguration.Instance.IndexPrefix ) );

dove l’ultima riga cambia la naming convention degli indici leggendo il prefisso dal file di configurazione. Enjoy!

Gestione dello schema database tramite NHibernate

imperugo — Mon, 13 Dec 2010 16:45:00 GMT

Dopo mesi di assenza, finalmente trovo di nuovo il tempo di “bloggare”, e la mia intenzione, questa volta, è di parlare di NHibernate (fresco di GA), di cui sto facendo un uso abbastanza “spinto” in un progetto.
Nello specifico ho avuto l’esigenza di dover gestire con NHibernate la creazione del database - e fin qui nulla di speciale - ma con l’obbligo di creare anche delle funzioni SQL per i vari databases supportati.

Uno dei principali requirements dell’applicazione è il supporto a ben tre versioni differenti di Sql Server più due di Oracle; per come sono strutturati il dominio ed il database, per poter effettuare determinate queries ho dovuto far uso di alcune funzioni lato database, in quanto non riproducibili tramite Object Query Language.

Fortunatamente NHibernate permette di utilizzare delle funzioni SQL Custom all’interno delle proprie queries sia se si fa uso di HQL, sia di Criteria API che di Linq.
Il loro utilizzo è veramente semplice; per prima cosa è necessario creare un proprio dialect, che erediti da quello più adatto al nostro database, e registrare le funzioni all’interno del suo costruttore, come mostrato dal codice seguente:

internal class SqlServer2008Dialect : MsSql2008Dialect {
    
    /// <summary>
    /// Initializes a new instance of the <see cref="SqlServer2008Dialect"/> class.
    /// </summary>
    public SqlServer2008Dialect ( ) {

        string monthFunction = string.Format("{0}.IsMonth", NHConfiguration.Instance.DatabaseSchema);
        string yearFunction = string.Format("{0}.IsYear", NHConfiguration.Instance.DatabaseSchema);

        base.RegisterFunction ( "IsMonth" , new StandardSQLFunction ( monthFunction , NHibernateUtil.Int32 ) );
        base.RegisterFunction ( "IsYear" , new StandardSQLFunction ( yearFunction , NHibernateUtil.Int32 ) );
    }
}

A questo punto possiamo utilizzare la funzione all’interno delle nostre query in maniera molto semplice:

Session.CreateQuery ( "from Article p where IsMonth( p.PublishDate ) = :month and IsYear( p.PublishDate ) = :year" )
    .SetParameter("month",month)
    .SetParameter("year", year)
    .SetFirstResult(pageIndex * pageSize)
    .SetFirstResult(pageIndex * pageSize)
    .SetMaxResults(pageSize)
    .SetReadOnly(!enableTracking)
    .List<Article>();

Come già detto in apertura, una delle caratteristiche dell’applicazione è la creazione ed aggiornamento del database tramite Nhibernate, il che si traduce nell’aggiungere gli scripts di creazione delle funzioni SQL lato codice; tuttavia, essendo lo schema del database impostato lato configurazione, è necessario manipolare gli scripts prima che questi siano “dati in pasto” a NHibernate per la creazione dello schema.

Gli steps da seguire sono pochi e piuttosto semplici, a dimostrazione dell’ottima struttura e flessibilità offerta da NHibernate. Per prima cosa è necessario preparare gli scripts di creazione e cancellazione delle funzioni SQL, tipo la seguente:

--SCRIPT DI CREAZIONE

CREATE FUNCTION [IsMonth]
       (
@date datetime
       )
       RETURNS int

       WITH EXECUTE AS CALLER
AS
BEGIN
  IF @date IS NULL RETURN 0
    RETURN Datepart(mm,@date)
END

GO

CREATE FUNCTION [IsYear]
(
  @date datetime
)
RETURNS int

WITH EXECUTE AS CALLER
  AS
  BEGIN
    IF @date IS NULL RETURN 0
      RETURN Datepart(yy,@date)
  END

GO

--SCRIPT DI CANCELLAZIONE

IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[IsMonth]') AND type in (N'FN', N'IF', N'TF', N'FS', N'FT'))
    DROP FUNCTION [IsMonth]
GO

IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[IsYear]') AND type in (N'FN', N'IF', N'TF', N'FS', N'FT'))
    DROP FUNCTION [IsYear]
GO

È importante rimuovere gli schema del database tipo “dbo” dallo script, in modo da poter aggiungere lo schema desiderato a runtime.

A questo punto va preparato un file XML di mapping che conterrà questi scripts, come mostrato di seguito:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">
    <database-object>
        <create>
      <!-- Inserire qui gli script di creazione -->
        </create>
        <drop>
      <!-- Inserire qui gli script di cancellazione -->
        </drop>
    </database-object>
</hibernate-mapping>

Da qui in poi è sufficiente eseguire una Regular Expression per poter aggiungere lo schema proveniente dal nostro file di configurazione e, solo a questo punto, è possibile passare a NHibernate il codice di XML contenente gli scripts di creazione e cancellazione delle funzioni.

db.Dialect<SqlServer2008Dialect>();
db.Driver<SqlClientDriver>();
databaseObjects = Resources.DatabaseObjects.MsSQL2008;

if (databaseObjects != null)
    databaseObjects = Regex.Replace(databaseObjects, @"(\[.*\])", string.Format("[{0}].$1", dbSchema));

if (!string.IsNullOrEmpty(databaseObjects)){
    //configuration è la configuration di NHibernate
    configuration.AddXmlString ( databaseObjects);
}

Anche in scenari in cui non si abbia l’esigenza di dover supportare diverse tipologie di database, consiglio sempre, quando possibile, di lasciare l’onere della creazionde del database all’ORM, in modo da poter creare e cancellare lo schema del database durante l’esecuzione dei nostri integration tests con molta semplicitià.

Ciauz

Introduzione a ConfORM

imperugo — Mon, 20 Sep 2010 15:45:00 GMT

Chi mi segue su Twitter sicuramente saprà che ultimamente mi sono messo a “giocare” un po’ con ConfORM, e, nello specifico, ho deciso di rimpiazzare FluentNHibernate in Dexter, per far strada al Framework prodotto da Fabio Maulo.

Per chi non lo conoscesse, ConfORM è un Framework che facilità incredibilmente tutta la parte di mapping del nostro dominio - quando si utilizza NHibernate per la persistenza - cambiando totalmente l’approccio; ma andiamo per gradi.

Oggigiorno esistono diversi modi di scrivere il mapping per NHibernate, partendo dal classico e mai datato XML, fino ad arrivare a Framework più recenti come FluntNHibernate, Ddl2Hbm, VisualNHibernate, etc.
Purtroppo questi framework hanno lo stesso approccio, obbligandoci a specificare la corrispondenza di ogni singola property di ciascuna classe di dominio verso il database.

Non conosco i vostri gusti relativamente alla scrittura di codice, ma personalmente ritengo molto noiosa e ripetitiva la fase di stesura del mapping, motivo per cui ConfORM la vince su tutti gli altri.

L’approccio di ConfORM.

Come già accennato ConfORM ha preso totalmente un’altra strada; di fatto inizialmente può lasciare l’utente un po’ spiazzato, ma quando si è capito il funzionamento è sicuramente un viaggio di sola andata, in quanto induce ad abbandonare totalmente il mapping “tradizionale”.
Di fatto quello che è necessario fare è “istruire” ConfORM con le nostre “regole” di sviluppo e di nomenclatura e specificare solo le eventuali eccezioni, lasciando a lui il compito di generare e gestire tutta la fase di mapping.

Per capire meglio il vantaggio, il grafico seguente mostra il Dominio di Dexter che in precedenza era mappato con FluentNHibernate in 27 classi differenti ed ora è mappato in poco più di 20 righe di mapping

Maggior Produttività e controllo.

Un altro vantaggio sicuramente interessante è l’aumento di produttività: possiamo aggiungere e togliere classi al nostro dominio senza toccare il mapping, a condizione che queste rispettino le regole stabilite precedentemente.
Quest’aspetto è sicuramente molto interessante perché ci permette di modificare il dominio senza preoccuparci di dover aggiornare il mapping, e riduce il rischio di introdurre errori dovuti ai continui cambiamenti.
Un altro aspetto che adoro è la rigidità che si può introdurre nel lavoro in team, in quanto se qualche sviluppatore non rispetta le regole di mapping prestabilite è obbligato ad andare a dichiarare l’eccezione manualmente e quindi il cambiamento è facilmente identificabile; un esempio banale potrebbe essere la nomenclatura delle tabelle: si è stabilito che sul database esse debbano chiamarsi con il nome della classe di dominio ma al plurare e, se un dev vuol chiamare la tabella in maniera differente è obbligato a gestire lo special case a mano e specificarlo nel mapping.

Performance:

L’utilizzo di ConfORM porta anche vantaggi prestazionali alla nostra applicazione in quanto, a differenza di tutti gli altri Framework di mapping, genera direttamente le classi necessarie a NHibernate per il suo utilizzo, saltando così tutta la fase di parsing del file xml contenente il mapping.
Ovviamente quest’aumento di performance è beneficiabile solo in fase di startup ed è sicuramente apprezzabile quando si ha a che fare con domini piuttosto corposi.
Per capire meglio il funzionamento di ConfORM rispetto al classico mapping o ad altri Framework, riporto qui un grafico “rubato” dal blog di Fabio che spiega perfettamente il perché dell’aumento di performances.

Conclusioni:

Ovviamente seguiranno altri post che mostreranno la parte più tecnica di ConfORM, ma per chi non volesse aspettare riporto alcuni link utili:

Download di ConfORM – Download.
Una serie di post su ConfORM è disponibile qui.

Enjoy your mapping.

Uno UserType generico per gli Enums

imperugo — Fri, 11 Sep 2009 21:30:32 GMT

NHibernate tende a mappare gli Enums come stringhe nel database; questo a volte può non essere un problema, ma personalmente preferisco memorizzarli in un intero, o ancora meglio un tynint, infatti con questo tipo di formato si ha un netto risparmio di spazio, ma anche un vantaggio per eventuali query.

NHibernate permette di cambiare il modo di persistere un tipo di oggetto del nostro domain model sul database tramite delle apposite classi; tradotto più semplicemente permette di avere una classe sulla propria entity e un semplice campo nel database (ad esempio un intero o un varchar), come potrebbe essere il CultureInfo che, in una classe come quella mostrata di seguito, è un oggetto, mentre sul database una semplice string tipo “en-US”.

public class Comment : EntityBase
{
    public virtual Item Item { get; set; }
    public virtual DateTime CommentDate { get; set; }
    public virtual string Message { get; set; }
    public virtual string Name { get; set; }
    public virtual string Email { get; set; }
    public virtual bool Notify { get; set; }
    public virtual string WebSite { get; set; }
    public virtual bool Approved { get; set; }
    public virtual bool IsSpam { get; set; }
    public virtual System.Globalization.CultureInfo Culture { get; set; }
}

Lo stesso approccio può essere utilizzato per gli Enums, quindi un enum come il seguente:

public enum BlogRollFriendType : short 
{
    Nothing = 0,
    Contact = 1,
    Friend = 2,
    Acquaintance = 3
}

può essere persistito come un tinyint sul database grazie ad uno UserType come quello mostrato di seguito:

public class GenericEnumMapper<T> : IUserType
{
    #region IUserType Members

    public new bool Equals(object x, object y)
    {
        if (ReferenceEquals(x, y)) return true;
        if (x == null || y == null) return false;
        return x.Equals(y);
    }

    public int GetHashCode(object x)
    {
        return x.GetHashCode();
    }

    public object NullSafeGet(IDataReader rs, string[] names, object owner)
    {
        object obj = NHibernateUtil.Int16.NullSafeGet(rs, names[0]);

        if (obj == null)
            return null;

        return (T) obj;
    }

    public void NullSafeSet(IDbCommand cmd, object value, int index)
    {
        if (value == null)
            ((IDataParameter) cmd.Parameters[index]).Value = DBNull.Value;
        else
            ((IDataParameter) cmd.Parameters[index]).Value = (short) value;
    }

    public object DeepCopy(object value)
    {
        return value;
    }

    public object Replace(object original, object target, object owner)
    {
        return original;
    }

    public object Assemble(object cached, object owner)
    {
        return cached;
    }

    public object Disassemble(object value)
    {
        return value;
    }

    public SqlType[] SqlTypes
    {
        get { return new[] {new SqlType(DbType.Int16)}; }
    }

    public Type ReturnedType
    {
        get { return typeof (T); }
    }

    public bool IsMutable
    {
        get { return false; }
    }

    #endregion
}

L’implementazione è piuttosto semplice, l’unica accortezza che bisogna avere per poter persistere l’enum come tinyint è specificare lo usertype nel mapping, come mostrato di seguito:

public BlogRoll()
{
    Table("BlogsRoll");
    DynamicUpdate();
    LazyLoad();
    Cache.NonStrictReadWrite();

    Id(x => x.ID)
        .GeneratedBy.Identity();

    Map(x => x.Name)
        .Not.Nullable()
        .Length(100);

    Map(x => x.Link)
        .Not.Nullable()
        .Length(100);

    Map(x => x.IsMyBlog);
    Map(x => x.FriendType)
        .CustomType(typeof(Dexter.NHibernate.Helpers.UserTypes.GenericEnumMapper<BlogRollFriendType>));

    Map(x => x.GeographicalType)
        .CustomType(typeof (Dexter.NHibernate.Helpers.UserTypes.GenericEnumMapper<BlogRollGeographicalType>));
}

Lo screenshot seguente mostra la struttura della tabella:

Testare il mapping di NHibernate

imperugo — Wed, 09 Sep 2009 08:49:05 GMT

Un buon mapping è la base di un buon risultato ottenibile tramite l’uso di un O/RM.
Anche se in molti esempi può sembrare semplice effettuare il mapping, in applicazioni reali (o con particolari richieste) questo può essere tutt’altro che semplice.
In Dexter ho avuto la necessità di realizzare diversi UserType per gestire enumerati, timezone, conversioni, ecc, ed ovviamente, essendoci una logica di calcolo dietro, questi andrebbero testati per evitare di avere un’incongruenza di dati o, nel peggiore dei casi, degli errori.
FluentNHibernate mette a disposizione delle classi che permettono di effettuare lo UnitTest del mapping verificando così che la CRUD della entity funzioni a dovere; quindi, nello specifico, si ha a disposizione un mini Framework per testare le seguenti operazioni:

Inserimento della entity;
Modifica della entity;
Recupero della entity;
Cancellazione della entity;

Lo snippet seguente mostra come effettuare questo tipo di test con poche righe di codice, avendo la certezza che il mapping sia corretto:

[TestMethod]
public void BlogRollMap()
{
    new PersistenceSpecification<BlogRoll>(session)
        .CheckProperty(c => c.ID, 1)
        .CheckProperty(c => c.Co_worker, true)
        .CheckProperty(c => c.Colleague, true)
        .CheckProperty(c => c.Crush, true)
        .CheckProperty(c => c.Date, true)
        .CheckProperty(c => c.FamilyType, BlogRollFamilyType.Sibling)
        .CheckProperty(c => c.FriendType, BlogRollFriendType.Contact)
        .CheckProperty(c => c.GeographicalType, BlogRollGeographicalType.Neighbor)
        .CheckProperty(c => c.IsMyBlog, true)
        .CheckProperty(c => c.Link, "http://www.microsoft.com")
        .CheckProperty(c => c.Met, true)
        .CheckProperty(c => c.Muse, true)
        .CheckProperty(c => c.Name, "Microsoft")
        .CheckProperty(c => c.Position, 1)
        .CheckProperty(c => c.Sweetheart, true)
        .CheckProperty(c => c.Username, "imperugo")
        .VerifyTheMappings();
}

Inoltre per condizioni particolari è possibile specificare, tramite l’apposito overload del costruttore, una classe IEqualityComparer per effettuare una comparazione custom dei dati, come mostrato di seguito:

public class SiteConfigurationEqualityComparer : IEqualityComparer
{
    public new bool Equals(object x, object y)
    {
        if (x == null || y == null)
            return false;

        if (x is TimeZoneInfo && y is TimeZoneInfo)
            return ((TimeZoneInfo)x).Id == ((TimeZoneInfo)y).Id;

        if (x is ReCaptcha && y is ReCaptcha)
        {
            var r1 = (ReCaptcha)x;
            var r2 = (ReCaptcha)y;

            return (r1.Enable == r2.Enable &&
                    r1.PrivateKey == r2.PrivateKey &&
                    r1.PublicKey == r2.PublicKey &&
                    r1.Theme == r2.Theme);
        }
}

Maggiori info sono disponibili qui.

Ciauz

FluentNHibernate 1.0 RTM

imperugo — Mon, 31 Aug 2009 09:36:37 GMT

Era già nell’aria (maggiori info qui), ed infatti è disponibile la versione RTM di FluentNHibernate 1.0 come annunciato dal blog di NHibernate qui.

Tutti i changeset del FluentMapping, AutoMapping e Conventions le trovate qui, mentre a questo indirizzo trovate il download.

Buon Mapping :)

Fluent NH 1.0 in RC.

imperugo — Sat, 22 Aug 2009 11:15:44 GMT

NHibernateFluent è una valida alternativa al metodo classico (XML Based) di mappare le entity con con NHibernate.
Nello specifico, il mapping non avviene più tramite la costruzione di un XML da embeddare nel progetto, ma scrivendo semplice codice C#. Anche se tramite gli appositi XSD si può disporre dell’intellisense durante la stesura dell’XML, l’approccio Fluent offre ulteriori vantaggi.

La cosa più interessante è che, nel caso di renaming di alcune proprietà, si ha già il mapping aggiornato, cosa che precedentemente al fluent era fattibile solo tramite l’uso di appositi plugin come Resharper: nel caso non si avesse avuto a disposizione questo addon spesso ci si imbatteva in alcuni problemi (come l’errata scrittura di una proprietà) solo a runtime, mentre ora l’errore si avrebbe a compile time, con un vantaggio notevole per lo sviluppatore.
Oltre a ciò, grazie alle lambda, la scrittura del mapping è molto più fluente (non a caso si chiama Fluent), come dimostra lo snippet seguente:

public class CatMap : ClassMap<Cat>
{
  public CatMap()
  {
    Id(x => x.Id);
    Map(x => x.Name)
      .Length(16)
      .Not.Nullable();
    Map(x => x.Sex);
    References(x => x.Mate);
    HasMany(x => x.Kittens);
  }
}

Personalmente ho iniziato ad usare il Fluent già dalla versione 0.1 - praticamente la prima versione - con non pochi problemi relativamente alle composite unique key, ma ora che è alla versione 1.0 RC (dal 16 di agosto), confido che i problemi siano risolti e che sia già utilizzabile alla grande.

Inoltre credo (qualcuno me lo ha detto, ma non ricordo chi) che il Fluent sia già presente nella trunk di NHibernate 3, ma questa notizia prendetela con le pinze :)

Ciauz

Maggiori info sul Fluent le trovate qui e qui.

LinqToNHibernate 1.0 is Out

imperugo — Sun, 26 Jul 2009 06:09:57 GMT

Lo ha annunciato Ayende in questo post, mentre il download lo trovate qui.

Ora non resta che provarlo.
Stay Tuned!

NHibernate 2.1 in RTM

imperugo — Mon, 20 Jul 2009 15:29:03 GMT

Forse sarà una settimana intensa di RTM (Release to Manufacturing), ma intanto godiamoci la version 2.1 di NHibernate appena annunciata da Ayende qui.

Come detto da lui è consigliato fare l’upgrade alla nuova versione che corregge numerosi Bug.

Il download lo trovate qui.

Enjoy.

Il blog di Ugo Lattanzi | ASP.NET, MVC, .NET Framework, WCF, WF, NHibernate, Linq, Microsoft

Gestione dei DateTime ed i vari TimeZone

Related Content

ConfORM, NHibernate, Oracle e gli Integration Test

Related Content

Gestione dello schema database tramite NHibernate

Related Content

Introduzione a ConfORM

L’approccio di ConfORM.

Maggior Produttività e controllo.

Performance:

Conclusioni:

Uno UserType generico per gli Enums

Related Content

Testare il mapping di NHibernate

Related Content

FluentNHibernate 1.0 RTM

Related Content

Fluent NH 1.0 in RC.

Related Content

LinqToNHibernate 1.0 is Out

Related Content

NHibernate 2.1 in RTM

Related Content