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 );