Fluent NHibernate 1.1

Out in the wild :-) .m Technorati Tags: NHibernate,Fluent Interfaces


Radical: Ensure, un altro update :-)

Questa volta Ughetto ha colpito nel segno. Sfruttando le “fluent interfaces” e i tricks per costruirle ho ridotto lo scope di un paio di metodi di Ensure<T> che potevano portare a comportamenti fuorvianti. Adesso il metodo Named( … ) compare


Fluently.Design().Me: quanto è facile prenderlo per i fondelli :-)

…l’intellisense :-) Questo test è meraviglioso, generics e anonymous types alla massima potenza: [TestMethod] public void asyncWorker_expecting_anonymous_type_as_result_should_correctly_set_result() { var wa = new ManualResetEvent( false


Fluently.Design().Me: inganniamo l’intellisense :-)

Per la felicità di Raffaeu ;-) Eravamo rimasti qua: Il giochetto è più semplice del previsto, avete quasi sempre due attori: Un entry point che tipicamente è una classe statica non generica che espone dei metodi generici; Una classe che v


Fluently.Design().Me: “coding experience requirements”

Abbiamo inziato a parlare di Fluent Interfaces. Perchè una Fluent Interface? 2 motivi: è un gran comodo poter “guidare” l’utilizzatore finale facendo si che l’intellisense vi proponga solo le cose sensate per il contesto corrente; è un gran


Fluently.Design().Me e il vero problema del design di una fluent interface

Partiamo dal problema: le closure. Facciamo un paio di esempi: this.HasMany( e => e.Advertisements ) .KeyColumnNames.Add( "PublishQueue" ) .Cascade.AllDeleteOrphan() .Access.AsCamelCaseField( Prefix.Underscore );


Castle Windsor: la registrazione dei componenti.

Si sa sono un fun di Castle Windsor e in generale del mondo IoC, una cosa però veramente tediosa, prona ad errori, scomoda e decisamente ingombrante dei framework di Inversion of Control è la gestione del file di configurazione, soprattutto se ...