Mauro and the sustainable development

What am I learning from the document database experience?

2012-02-09T14:37:00.000+01:00

I’ve recently worked on a really interesting project based on RavenDB and NServiceBus, there will be a lot of time to deeply speak about it.

This argument should be treated at least in a 1h talk or far better in an open panel discussion…if someone is interested ping me, we can do that!

Document databases perfectly suites some DDD principles, such as the concept of aggregate; be aware that I’m not saying that relational databases does not suite, this post is not about relational versus document (I dislike the “no-sql” name).

Read on…questions

After the “document-db” experience I asked myself one single question: why do I need an ORM?
The short answer is: we tend to introduce an ORM to solve a problem that we have introduced.
So…if we do not introduce the first problem do we need an ORM anymore? basically yes, but now the question “moves” to: what an ORM should do for us?
The short answer is in the name: ORM –> map relational data to objects (period).

Abuse

ORM(s) per se are a wonderful thing, as with everything, problems come with the abuse of the wonders …typically what I hear from the field is something like: “I want to get rid of all that SQL strings that pollute my code”…
…and? they end up using hql strings with NHibernate…what is the difference? why the hell you want to hide SQL code from your program and then you want to view the generated SQL using a profiler?
I suppose, well at least it is what generally happens to me, that when we face the design of the database we tend to forget which will be, at the application level, the usage of the data we are designing…we tend to follow design guidelines and design rules instead of saying “I need the data in that shape, period”…and then we masturbate that data with an ORM to shape the perfectly normalized data in the form we really want them…

Astute…isn’t it?

Listen to me: give it up! try once to go back to the origin, use SQL, use Stored Procedures, design your data as you need them not as the book told you to design them…once you re-learned the “story” do you own choice, there are ton of tools out there that follows the “keep it simple, Luke” pattern:

Conclusion(s)

I suppose that the human kind is basically stupid and tends to forget too easily the past…”they” gave us SQL, then someone invented the ORM (I’ll repeat myself: a wonder, really) and we forgot that the ORM is basically a way to get rid of the SQL it is not a “replacement”, then ORM guys start to over-engineer giving us lot’s of features on top of ORM(s)…features that, if you use an Object Model, can be really lifesavers such as Identity Map or Unit of Work but gave us also the vacuum cleaner that let us hide under the carpet bad data design decisions…and obviously we start to use all that cool features…producing tons of joins or select n+1 and looking at SQL, yeah old hated SLQ hidden under the carpet, in a profiler to understand what is going on…why the hell our application is so slow…
Give a try to document databases, not because they are better than relational ones (they are not, both have pros and cons) but because they force your mind to go back to the basics, they force you to understand some DDD principles (such as Aggregates and Bounded Contexts) and they let us see the light at the and of the tunnel giving us the opportunity to completely re-think our approach to the relational model.

.m

UGIAlt.Net

2012-02-07T23:15:00.001+01:00

I would like to thank all the guys at the UGIAlt.Net user group for the amazing conference held in Milan where I gave a talk about RavenDB:

You can find the slide deck and samples on SkyDrive and the talk recording on Vimeo.

Community Days 2012

2012-02-07T23:06:00.001+01:00

Community Days 2012 are approaching, I’m excited because I’m going to give a talk about NServiceBus in real, real real , scenario.

See you there.

Interesting Roslyn usage(s)

2012-02-07T12:17:00.001+01:00

take a look here, really interesting…really.

RavenDB: first contact

2012-02-06T10:10:00.000+01:00

We have seen how to setup the development environment to use RavenDB, obviously the next step is to try to use our brand new environment.

NuGet to the rescue

First of all let’s setup the Visual Studio project to use RavenDB, using nuget as simple as adding a package reference to the RavenDB nuget package:

Figure: nuget installation dialog

the package installation downloads all the required dependencies and setup the application configuration file with the required connection string, that obviously must be adapted to your environment:

Figure: the application configuration file customized for my environment, where RavenDB server listen on port 81

The basics

RavenDB has 2 main building block that must be understood in order to manage all the features, having had previous experience with NHibernate can help in this area because the RavenDB API has been designed to help ORM users to migrate and stay in well known environment.

IDocumentStore

The IDocumentStore interface is the counterpart, for ORM users, of the NHibernate ISessionFactory there should (we’ll see in future posts why “should” and not must) be one document store per each RavenDB server we need to access.

Figure: the creation and initialization of the document store

the document store has several properties that we can use to customize the behavior of the connection, the security and the behavior of the store itself.

The only really required thing to do is to initialize, once, the store calling the quite obvious “Initialize” method.

IDocumentSession

the document session interface, that mimics the NHibernate ISession behaviors, is the entry point to access data stored on a RavenDB server instance. The document session is also our “Unit Of Work” implementation that let us manage business transactions against the server.

Connection to a database is as easy as:

Figure: the creation of a document session

where “myMusic” is the name of the database where I created the sample data, if we do not specify the database name the connection will be made against the default database (that always exists) or against the default database specified before the document store initialization using the DefaultDatabase property (we can also specify the default database in the connection string.

So far so good…so what?

…let’s try to pick some data…just try:

Figure: some data retrieved in a rather funky way

Cool! what’s going on? we have done a really strange thing we have used the generic Query method, closed against a .net 4.0 dynamic type, asking for the first 10 items…and we received back 10 items…not so expected as it can seem at a first look.

A little digression…little, trust me…

In order to figure out what has happened when the above query has been executed we need to understand how data (document) are stored in a document database.

No tables here guys , the above linq query can be compared to the following, invalid, T-SQL statement:

select top 10 *
go

That obviously has no meaning in a relational world because lacks, al least, the “from <table-name>” clause. Document databases has the concept of collection that represents an homogeneous subset of data and in RavenDB the subset you want to query over is expressed by the .net generic type you choose for the Query method (it is not really true, but for the moment it’s good enough).

Let’s move on

If we take a look at the database using the Raven Management Studio we can see that there are 2 different collections: Albums and Genres.

Figure: collection contained in the database

Which is the easiest method to tell to the document session that we want to query the albums collection? remember easiest.

Just define an Album type with the same shape of the json document stored in the database

Figures: on the left side the Album type definition on the right side the json document that represents an album in the database

As you can see we have defined even complex types (AlbumGenre and AlbumArtist, we’ll have future posts to detail the concept of “relation”) that will be automatically mapped to the corresponding nested properties in the json document. One thing you may already have noticed is that the json document is the serialized version of the .net type.

Query

if we rewrite the above query using the Album type we fetch exactly 10 albums:

Figure: RavenDB query executed to retrieve 10 albums from the database

wundershon …but how can RavenDB “map” our .net type to its own internal representation? using one of the thousands of cool features that this database have: metadata.

Figure: the same document showing the metadata tab in the management studio.

each document has a set of extensible metadata attached to it and the important one in this case is the Raven-Entity-Name, the database engine utilizes a set of conventions to translate a .net type name to the so called “Raven tag name”:

Figure: using document store conventions to map .net type name to Raven tag name.

Enough for this post…next time is time for “storing data”

it works (period)

2012-01-31T17:00:00.000+01:00

2 years ago…

I wrote, speaking about task boards (concrete board):

Interaction with a concrete panel, directly accessible by the customer has a great collateral effect:

our client says: I would love to have also this small feature…it’s a cheap change for you guys (WTF…I can say if it’s cheap or not…not you…)
- immediately a story takes its own place on the board;
- the “traffic” on the panel increases;
- our client directly perceives that stuff to do has increased, increased proportionally to each request;
The rate of questions like “which is the state of the art?” has dramatically dropped;
The client think a lot, looking at the board, before asking for a change request;

These only to say that online tools a really cool, but being able to physically touch the backlog has its own pros.

2 years later…

Today I can state that it works <cit.>, the board is not the same (from the design point of view) now it’s much more a Kanban board, than a Scrum one, with WIP limits determined by column sizes:

the effect is the same, and my PM only asks me “how you doing” in front of the coffee machine just to know how the weekend has gone and not to know how the project is growing

RavenDB: start your engines

2012-01-27T16:18:00.001+01:00

This post is intended to be an introduction to RavenDB and as all the introduction will deal with the basic steps required to setup the development machine.

The first step is to download the RavenDB binaries from the RavenDB site: http://ravendb.net/download#builds.
Once downloaded remember to unblock the compressed archive before extracting files to the hard drive.

First run

After the file extraction the directory structure should be something like the following:

Figure: file and folder structure from RavenDB build 573.

There are 2 different server versions (the highlighted folders in the above figure):

“Server” folder contains server binaries already setup to run as a console application or as a Windows service;
“Web” folder contains server binaries setup to run as an IIS hosted application;

During the development process the console version is a real life saver because it gives real time access to server logs. In order to start the console version it’s enough to jump into the server folder and double click on the Raven.Server.exe file.

What happens is that the server starts, the first time it can take some time due to the operation performed to setup the environment fir the first time. Once the server is started the console should look like the following screenshot:

Figure: the console running a RavenDB server instance.

Side note: you can be presented with the Windows Firewall authorization dialog, as the following:

Obviously you need to give appropriate permissions if you need to access your local server from another machine.

The console immediately gives some important information:

The data directory where data are stored;
The server url, host name and listening port;
The storage engine type, on Windows the default is Esent;

And now?

Once the server is running the first thing we can do is trying to connect using the builtin management studio, the studio is a Silverlight application that can be launched simply pointing the browser to the listening server Uri:

Figure: the RavenDB management studio running in Chrome.

Obviously the database, the default database that is created at server startup, is empty. At the bottom of the “summary” page there is a button that starts the creation process of a bunch of sample data. After the creation of the sample data your collections should look something like:

Figure: database collections just after the sample data creation process has completed.

The server console immediately confirms that something is going on at the server side:

Figure: the RavenDB server console showing real time logs.

Are you “secure”?

no…it’s not an Italian false friend, I’m pretty sure One question that some readers could raise is: how can it be that the server let a connected, and apparently anonymous, application to write data?

Well…

The first thing we need to understand is the RavenDB security model: when running in the console mode the default security model is Windows authentication (oAuth is an option too) and the access level, the anonymous access level, can be controlled via the server configuration file:

Figure: the configuration file showing the Raven/AnonymousAccess configuration setting.

The anonymous access setting support 3 different values:

None: anonymous access is not allowed;
Get: anonymous clients has just read-only permissions;
All: anonymous clients are full trusted clients and can do everything;

So?

As we can see the current running value is “Get”, but since the studio is connecting to localhost it is basically running in “intranet” mode and thus is passing the current user credentials to the RavenDB server that, using Windows authentication, can trust the incoming requests: that’s why we could create data even if no one asked us any credential.

Enough for the moment…next time we’ll see how to connect to the server using our own application.

This blog is moving…

2012-01-26T15:07:00.001+01:00

it is a requirement! I cannot go on scrounging hosting off Gian Maria and Alessandro and at the same time I do not want to pay an hosting plan just to host my own blog, after 3 years I can safely say that it is not sustainable….and since this blog title is “Mauro and the sustainable development”…

So far so good…but what’s happening?

Well…lot’s of things:

if you are reading this post means that the FeedBurner feed has been successfully updated to point to the new blog: http://mauroservienti.blogspot.com/;
the “old” blog (http://milestone.topics.it) is still alive and will be online until the posts migration process has been completed:
- I’ve written a tool to migrate posts from the old blog to Blogger, but blogger has a post limit (well a sort of) of 50 posts a day, so the migration process will last something like 16 days;
at the end of the migration process the old blog address will be redirected here in order to complete the migration;

This basically means that by the 15 of February I can free some resources of the Gian Maria and Alessandro server

Why BlogSpot?

There were, when I decided to move a couple of weeks ago, 2 main competitor:

WordPress;
BlogSpot;

Both free and with lots of interesting features, really a lot , but I was looking mainly for 2 features:

Custom domain, I need to point milestone.topics.it to the blog;
Custom pages: the ability top create “pages” other then posts;

Both the competitors offer these features but the custom domain is a paid feature for WordPress…BlogSpot is the winner…easy

In the End…

I’d like to thank:

First of all Ugo for Dexter and the support during these 3 year;
Gian Maria and Alessandro for the free hosting during the last months;

Thanks guys, I owe you a dinner.

DotNetMarche: Spettacolo!

2010-01-30T18:21:00.000+01:00

volevo ringraziare tutti, ma proprio tutti i partecipanti al Workshop di ieri organizzato da DotNetMarche.
Giornata perfetta e serata perfettissima: il porco ha fatto la sua porca figura! :-), un grazie particolare a Gian Maria per l’ospitalità e lo scarrozzamento.
.m

CommandBinding: MarkupExtension

2010-01-30T12:39:00.000+01:00

Estendere il motore di DataBinding, a oggi, è impossibile perchè è tutto internal e/o sealed… immagino abbiano avuto i loro buoni motivi e posso immaginare anche quali siano, sta di fatto che è una gran menata…
Possiamo però partire da questo post, come suggerito da Giuseppe, e wrappare la classe Binding in una nostra classe Binding esponendo le stesse identitche proprietà che saranno dei meri proxy verso la classe Binding reale; facendo infine semplicemente questo:

public override object ProvideValue( IServiceProvider provider )
{
    return binding.ProvideValue( provider );
}

Nel momento in cui la nostra markup extension viene effettivamente invocata l’unica cosa che possiamo fare è passare la palla alla vera markup extension con cui Wpf è in grado di interagire.
Ma non è ancora tutto perso… se usiamo M-V-VM siamo probabilmente molto avvezzi al concetto di DelegateCommand/RelayCommand e alla possibilità di scrivere una cosa di questo genere:

var command = DelegateCommand.Create()
    .AddKeyGesture(
            System.Windows.Input.Key.S,
            System.Windows.Input.ModifierKeys.Control )
    .OnExecute( o => { /* execution logic */ } );

con lo scopo di creare un ICommand a cui sia implicitamente associata la combinazione Ctrl+S peccato che quella cosa non funzioni perchè nessuno (aka la classe Binding) si preoccupa di eseguire la registrazione degli Input Bindings…
Sfruttando quindi la nostra bella markup extension perchè non realizzare qualcosa del genere:

public class CommandBinding : BindingDecoratorBase
{
    public override object ProvideValue( IServiceProvider provider )
    {
        var b = base.ProvideValue( provider );
        this.OnProvideValue( provider, b );
        return b;
    }

    protected virtual void OnProvideValue( IServiceProvider provider, Object value )
    {
        FrameworkElement fe;
        DependencyProperty dp;

        if( this.TryGetTargetItems<FrameworkElement>( provider, out fe, out dp ) )
        {
            RoutedEventHandler reh = null;
            reh = ( s, e ) =>
            {
                fe.Loaded -= reh;
                this.OnTargetLoaded( fe, dp );
            };
            fe.Loaded += reh;
        }
        else
        {
            FrameworkContentElement fce;
            if( this.TryGetTargetItems<FrameworkContentElement>( provider, out fce, out dp ) )
            {
                RoutedEventHandler reh = null;
                reh = ( s, e ) =>
                {
                    fce.Loaded -= reh;
                    this.OnTargetLoaded( fce, dp );
                };
                fce.Loaded += reh;
            }
        }
    }

Con TryGetTargetItems definita così:

protected virtual bool TryGetTargetItems( IServiceProvider provider, out T target, out DependencyProperty dp )
    where T : DependencyObject
{
    target = null;
    dp = null;
    if( provider == null ) return false;

    var service = provider.GetService( typeof( IProvideValueTarget ) ) as IProvideValueTarget;
    if( service == null ) return false;

    target = service.TargetObject as T;
    dp = service.TargetProperty as DependencyProperty;
    return target != null && dp != null;
}

Abbiamo la necessità di sapere quando il target del Binding è “Loaded”, tracciamo sia FrameworkElement (eg Button) che FrameworkContentElement (eg Hyperlink) perchè purtroppo () non hanno lo stesso ancestor e quindi hanno 2 eventi Loaded diversi… poco male, basta saperlo.

    protected virtual void OnTargetLoaded( DependencyObject target, DependencyProperty targetProperty )
    {
        var source = target as ICommandSource;
        var command = this.GetCommand( target, targetProperty );
        this.SetInputBindings( target, source, command );
    }

A questo punto quando il target è Loaded ci limitiamo ad estrarre dalla DepenedencyProperty (omesso per brevità) il valore dell’ICommand e non facciamo altro che impostare gli imput bindings sul root element, anche qui la funzione ricorsiva che va alla ricerca del root element è omessa:

protected virtual void SetInputBindings( DependencyObject target, ICommandSource source, IBindableCommand command)
{
    if( source != null && command != null && command.InputBindings != null )
    {
        var rootElement = this.GetRootElement( target as FrameworkElement );
        foreach( InputBinding ib in command.InputBindings )
        {
            if( ib.CommandParameter != source.CommandParameter )
            {
                ib.CommandParameter = source.CommandParameter;
            }

            rootElement.InputBindings.Add( ib );
        }
    }
}

Togo, adesso lo possiamo usare così:

<Button Height="23" Command="{cmd:CommandBinding Path=ExecuteSampleCommand}" />

Ottenendo gratis la registrazione degli input bindings.
Ma non è finita… Stay tuned!
.m

UserExperience: ma quanto mi costi?

2010-01-28T06:31:00.000+01:00

Wpf mi ha catapultato in un mondo affascinante e che conosco poco, il mondo della User Experience, la cosa bella è che da lunedì verrò assorbito e avvolto totalmente da questo mondo in quanto uno dei principali focus di Gaia.
L’esperienza di questi ultimi mesi però mi ha fatto rivalutare la scala dei “costi” dello sviluppo mettendo ampiamente in testa alla classifica della cosa più onerosa proprio una User Experience di qualità.
Wpf in questa direzione aiuta veramente tanto perchè se penso alle stesse cose fatte con Windows Forms decisamente meglio un carciofo nel… ;-)
Giusto per capirci, ne parleremo parecchio, osservate gli esempi qui di seguito:

Sono un wizard, e anche se io odio tanto gli wizard, per l’utente finale sono veramente la manna in termini di semplificazione del processo e di focus sulle cose importanti, ma… passare da uno singolo “screen” ad uno wizard comporta come minimo un po’ di problemi nella gestione della validazione che passa da globale a scoped alla pagina che l’utente sta guardando; e non è proprio un’operazione semplice;
Ma non solo, anche un wizard ha i suoi problemi, la prima versione che ho rilasciato era “bloccante” (vedi lo screenshot di sinistra) era quindi impossibile passare alla pagina successiva se quella corrente era in uno stato invalido. Questo però comporta un problema per l’utilizzatore… mancanza di feedback:

l’utente arriva sulla pagina in questione;
il pulsante “Avanti” è disabilitato perchè la pagina non è valida;
ma l’utente non capisce perchè, ed essendo “Avanti” disabilitato non ha nessun mezzo per triggerare la validazione;

In termini di UX la seconda soluzione è sicuramente migliore, anche se complica parecchio le cose:

Il pulsante “Avanti” è sempre attivo;
la prima volta che si arriva sulla pagina non ci sono errori;
se si pigia il pulsante avanti e la pagina non è valida:

il cambio pagina viene bloccato;
la validazione viene triggherata;
i controlli non validi vengono evidenziati (e questo con M-V-VM e IDataErrorInfo è abbastanza un delirio);

Oppure ci sono situazioni in cui potrebbe aver senso lasciare che l’utente prosegua nel processo e abbia, oltre alla validazione contestuale, un riepilogo degli errori in ultima “pagina”;

Giusto per capire perchè Wpf in questo senso è la manna, per fare tutto quello di cui sopra il designer si deve limitare ad utilizzare (e configurare) un Behavior:

Spettacolo!
.m

n.d.r.: Il controllo Wizard è gentilmente offerto da: divelements.com.

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

2010-01-27T12:14:00.000+01:00

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

    var expected = "result";
    var actual = "";

    var worker = AsyncWorker.Using( expected )
        .AndExpecting( new { Sample = "" } )
        .Configure( cfg =>
        {
            cfg.After = e => actual = e.Result.Sample;
        } )
        .Execute( e => e.Result = new { Sample = e.Argument } );

    worker.Completed += ( s, e ) => wa.Set();
    wa.WaitOne();

    actual.ShouldBeEqualTo( expected );
}

con “AndExpecting()” definito così:

public interface IInputWorker
{
    IConfiguredInputWorker Configure( Action<IInputWorkerConfiguration> cfg );
    IWorker Execute( Action<IAsyncArgs> async );

    IInputOutputWorker AndExpecting();
    IInputOutputWorker AndExpecting( TResult sample ); 
}

Sempre perchè anche la coding experience vuole la sua parte… un po’ come l’occhio :-)
A che scopo?
Semplicemente evitare la creazione di una tupla/dto in molti contesti in cui gli anonymous type(s) sono una soluzione ottimale.
L’inghippo è che con i generics siete obbligati a specificare il tipo T (in questo caso TResult) ma non è possibile specificare come tipo T un anonymous type; è però possibile, come evidenziato dal test, ingannare l’intellisense sfruttando la “Type Inference”: in questo caso passiamo al metodo AndExpecting() un tipo anonimo al solo fine di stimolare la Type Inference e far si che il tipo della proprietà “Result” abbia la stessa firma del tipo che abbiamo usato come esempio…
figo :-)
.m

Accorrete gente, accorrete :-)

2010-01-26T20:36:00.000+01:00

Dunque dunque… mi stavo quasi dimenticando.
Se venerdì 29/1 siete in zona Jesi e non avete nulla di meglio da fare potreste venirci a trovare all’evento di DotNetMarche su Wpf e dintorni.
E se non vi va di sentirci blaterare di UI Compositione Model-View-ViewModel potete sempre aggregarvi per la cena il cui titolo è: Sua maestà… il Porco… (slurp ;-) )
Questo il menù:

Aperitivo Peppe Cotto, con Ciauscolo, Vino Cotto di Loro e altre Porcherie
Vellutata di Zucca con Cotechino e Crostini
Pasta e Fagioli con Cotiche e Codine
Maialino in porchetta con patata alla griglia con Lardo di Cinta Senese
Dolce Cremoso al Mascarpone
Vini dell’Azienda Agricola Piantate Lunghe di Candia

… sono commosso :-)
Cioè… vi rendete conto: Vellutata di Zucca con Cotechino e Crostini…
.m

Dimenticavo… once again :-)

2010-01-26T04:40:00.000+01:00

Abbiamo parlato di “Ensure” e del suo rapporto con lo StackTrace ma mi sono dimenticato il pezzetto importante e giustamente Antonio se ne è accorto :-)
Eccoci:

class SourceInfo
{
    public readonly static SourceInfo Empty = new SourceInfo( "", "", MemberTypes.Custom );

    public SourceInfo( String methodName, String className, MemberTypes sourceType )
    {
        this.MethodName = methodName;
        this.ClassName = className;
        this.SourceType = sourceType;
    }

    public String MethodName { get; private set; }
    public String ClassName { get; private set; }
    public MemberTypes SourceType { get; private set; }
}

Utilizzando questa come dto possiamo scrivere qualcosa del tipo:

public static class Ensure
{
    public static Ensure That( T obj )
    {
        SourceInfo si = SourceInfo.Empty;

        var st = new StackTrace( 1 );
        if( st.FrameCount > 0 )
        {
            var f = st.GetFrame( 0 );
            var mi = f.GetMethod();
            if( mi != null )
            {
                si = new SourceInfo( mi.DeclaringType.Name, mi.Name, mi.MemberType );
            }
        }

        return new Ensure( obj, si );
    }
}

Che altro non fa che recuperare le informazioni sullo stack frame precedente al nostro che è necessariamente il chiamante.
A questo punto diventa abbastanza banale far passare un test come questo:

[TestMethod]
public void ensure_getFullErrorMessage_should_contain_all_relevant_information()
{
    var obj = Ensure.That( "" );
    String actual = obj.GetFullErrorMessage( "validator specific message" );

    var containsClassName = actual.Contains( typeof( ValidatorTest ).Name );
    var containsMethodName = actual.Contains( typeof( ValidatorTest ).Name );

    containsClassName.ShouldBeTrue();
    containsMethodName.ShouldBeTrue();
}

Wpf: Ogni tanto penso che si siano fumati il cervello…

2010-01-21T16:52:00.000+01:00

Si si avete capito bene, quelli che hanno disegnato l’api di Wpf :-S
Provate a fare una Window ridimensionabile con il mouse (con il ResizeGrip per intenderci) ma ne massimizzabile ne minimizzabile… con Windows Forms era una banalità, con Wpf non si può :-o
WindowControlBoxBehavior
la soluzione, pezza secondo me, è questa:

public sealed class WindowControlBoxBehavior : Behavior<Window>
{
    public Boolean AllowMaximize
    {
        get;
        set;
    }

    public Boolean AllowMinimize
    {
        get;
        set;
    }

    RoutedEventHandler h;

    public WindowControlBoxBehavior()
    {
        h = ( s, e ) =>
        {
            var isDesign = DesignTimeHelper.GetIsInDesignMode();
            var hWnd = new WindowInteropHelper( this.AssociatedObject ).Handle;

            if( !isDesign && hWnd != IntPtr.Zero && ( !this.AllowMaximize || !this.AllowMinimize ) )
            {
                var windowLong = NativeMethods.GetWindowLongPtr( hWnd, Constants.GWL_STYLE );

                if( !this.AllowMaximize )
                {
                    windowLong = windowLong & ~Constants.WS_MAXIMIZEBOX;
                }

                if( !this.AllowMinimize )
                {
                    windowLong = windowLong & ~Constants.WS_MINIMIZEBOX;
                }

                NativeMethods.SetWindowLongPtr( hWnd, Constants.GWL_STYLE, windowLong );
            }
        };
    }

    protected override void OnAttached()
    {
        base.OnAttached();
        this.AssociatedObject.Loaded += h;
    }

    protected override void OnDetaching()
    {
        this.AssociatedObject.Loaded -= h;
        base.OnDetaching();
    }
}

un po’ di sano P/Invoke utilizzabile via xaml così:

<i:Interaction.Behaviors>
    <bhv:WindowControlBoxBehavior AllowMaximize="False" AllowMinimize="False" />
i:Interaction.Behaviors>

producendo il risultato desiderato:

dove i bottoni per massimizzare e minimizzare non ci sono ma la finestra resta comunque ridimensionabile.
.m

VS2008 Forward Compatibility Update: BUG

2010-01-21T16:29:00.000+01:00

o come diamine l’hanno chiamata :-D, insomma questa KB: VS90SP1-KB974558-x86, okkio che c’è il rischio che vi sminchi (termine tecnico) la parte di Unit Testing di Visual Studio 2008.
Ne approfitto per ringraziare John Nierenberg che mi ha personalmente seguito nell’identificazione del BUG e mi ha pure fornito un workaround.
Il problema
L’aggiornamento in oggetto è necessario per rendere compatibile il Team Explorer di VS2008 con TFS 2010, senza l’aggiornamento l’essenziale funziona ma non è detto che si comporti come si deve (senza alcune cose in effetti fanno un po’ le bizze)
Sta di fatto che l’update si porta dietro una modifica al comportamento della finestra dei Test Results che quando si apre cerca nel Team Explorer un riferimento al Team Project corrente… giustamente se non c’è nessun Team Project il tutto sbomba, portando nella migliore delle ipotesi al fallimento dei test…
Il workaround
La soluzione, per chi è affetto dal problema, in attesa della RTM banalmente è quella di essere connessi ad un TFS, uno qualsiasi anche senza nessun Team Project.
Ne approfitto per ringraziare pubblicamente sia John che tutto il team di TFS che sta facendo un lavoro fondamentale: ascoltare i feedback.
Sono iscritto/partecipo ad una mailing list interna, insieme ad alcuni illustri colleghi, del team e c’è un’attività/proattività che definire frenetica è poco, i tempi di risposta spesso sono nell’ordine di pochi minuti nonostante i fusi orari dei partecipanti sparsi un po’ in tutto il mondo, e le discussioni spessissimo sfociano in modifiche a quella che sarà l’RTM di TFS2010 o quella che sarà la vnext.
Complimenti! decisamente.
.m

Questi due hanno un concetto di fatica tutto loro…

2010-01-21T14:04:00.000+01:00

non ho parole…
.m

Confrontarsi “smuove” i neuroni

2010-01-21T12:15:00.000+01:00

Questo è un fatto, comodo, da tempo:

readonly IEntityViewModelFactory viewModelFactory;

public PaymentMethodEditorViewModel( IEntityViewModelFactory viewModelFactory )
{
    Ensure.That( viewModelFactory ).Named( "viewModelFactory" ).IsNotNull();

    this.viewModelFactory = viewModelFactory;
}

se la validazione fallisce a runtime vi beccate un sana ArgumentNullException. Ci sono una notevole quantità di metodi e di extension methods che servono per validare gli scenari più disparati:

void MyMethod( String argument )
{
    Ensure.That( argument )
        .Named( "argument" )
        .WithMessage( "...ti sei dimenticato il parametro :-)" )
        .IsNotNullNorEmpty();
}

Fino a ieri aveva un solo difetto: era complessivamente complesso capire dove fosse realmente fallita la validazione perchè l’exception viene sollevata dalla libreria di validazione e non dal codice chiamante quindi l’unica possibilità era armarsi di pazienza e spulciare lo StackTrace… con l’inghippo che se il tutto è in un mondo multi-threading lo StackTrace è tutto tranne che developer friendly :-)
Una paio di giorni fa durante una ciaccolata con Marco De Sanctis salta fuori l’inghippo di cui sopra e stuzzicato dalla possbilità di risolverlo mi armo di curiosità e, grazie anche a uno scambio di mail con un paio di MVP d’oltreoceano (mirate a capire se c’era modo di ingannare il debugger), scopro che:

La proprietà StackTrace della classe Exception è virtual… :-)
c’è quindi la possibilità di manipolare a runtime lo StackTrace e rimuovere le informazioni che non servono…;
…ma questo probabilmente è poco bello oltre al fatto che comporterebbe una gerarchia custom di Exception;

perchè quindi non limitarsi ad utilizzare lo StackTrace per recuparare le informazioni necessarie a dettagliare meglio l’errore? facendo si che questo snippet:

static void Main( string[] args )
{
    try
    {
        Ensure.That( args )
            .Named( "args" )
            .WithMessage( "Missing console arguments." )
            .IsFalse( v => v.Length == 0 );
    }
    catch( ArgumentException e )
    {
        Console.WriteLine(e);
    }

    Console.Read();
}

produca questo:

Sempre perchè anche il developer vuole la sua parte :-)
.m

…dimenticavo :-)

2010-01-21T11:04:00.000+01:00

Anche io invecchio, uffa :-P
la chiaccherata con Marco de Sanctis era volta a capire perchè non avessi usato una sintassi di questo genere:

Ensure.That( () => args )
    .WithMessage( "Missing console arguments." )
    .IsFalse( v => v.Length == 0 );

che utilizzando le lambda mi permetteva di pigliare due piccioni con una fava:

rimuovere il nome del parametro che è una stringa non refactoring-friendly;
e passare contestualmente il valore da ispezionare;

In effetti quella cosa in origine c’era:

internal Ensure( System.Linq.Expressions.Expression<Func> obj )
{
    if( obj == null )
    {
        throw new ArgumentNullException( "obj", "Cannot use a null Expression> as Ensure ctor parameter." );
    }

    Func func = obj.Compile();
    this.inspectedObject = func();

    var expression = obj.Body as System.Linq.Expressions.MemberExpression;
    var member = expression.Member as System.Reflection.FieldInfo;
    this.Name = member.Name;
}

Decisamente figoso, peccato che quella chiamata a Compile(), per poi poter ottenere il valore, abbia un costo notevole che inficia in maniera percettibile sulle prestazioni complessive.
Il suggerimento resta comunque valido per soddisfare il primo punto e poter scrivere questo:

Ensure.That( args )
    .Named( () => args )
    .WithMessage( "Missing console arguments." )
    .IsFalse( v => v.Length == 0 );

Wpf: WeakEventManager

2010-01-21T06:39:00.000+01:00

Ci siamo da poco scontrati con il concetto di Logical e Visual Tree e con l’evidente necessità di tenere in ordine la memoria per consentire al GC di fare il suo lavoro quando serve, risulta però evidente, sempre più al crescere della soluzione, che lasciare per strada qualcosa potrebbe essere molto facile.
Weak*
Abbiamo già visto come una WeakReference possa essere un’ottima soluzione ad alcune problematiche, ribaltiamo adesso lo scenario e mettiamoci nel panni di una classe che aggancia un handler ad un evento: se la classe (target) che ha agganciato l’evento non ha modo di sapere quando e se il sender va out-of-scope è evidente che questo può portare ad un .net-memory-leak perchè il nostro target sta impedendo che il GC possa liberare la memoria occupata dal sender.
Wpf introduce il supporto a questo scenario estendendo il concetto di WeakReference e introducendo quello di WeakEventManager: un weak event manager è qualcuno che si mette in mezzo tra il sender e il target facendo da ponte tra i due e gestendo internamente una sorta di weak reference in modo che se il sender esce dallo scope possa venir correttamente gestito dal GC.
Si, ok… ma come si fa?
Inquadriamo prima il potenziale problema con un esempio:

In una UI come quella qui sopra succedono generalmente un po’ di cose, tra cui:

I bottoncini “impegnato” e “stampa” si attivano disattivano in base alla selezione nel documento sottostante… a patto che:
- Un documento sottostamte esista…;
- Un documento sottostante sia il documento attivo;
- etc…
Il ribbon reagisce al cambio di documento corrente “seguendo” come un segugio, sulla base di un set di regole il documento attivo: ad esempio se selezionate il documento “Home” automaticamente la tab “Home” del ribbon diventa quella attiva e se tornate ai risultati della ricerca la tab “Pubblicazioni” diventa quella attiva; ma se vi spostate su Home e poi manualmente riportate il ribbon su “Pubblicazioni” allora i pulsanti (di cui sopra) reagiscono di conseguenza disattivandosi perchè il documento attivo non è quello giusto;

Come potete immaginare in tutto questo giro di handling di eventi ce ne sono una vera montagna, non solo…, la cosa è complicata dal fatto che alcune parti di quella UI sono iniettate a runtime e sanno poco o nulla di chi le sta ospitando e chi le ospita proprio non sa nulla di loro.
Grazie al supporto dei command di Wpf diventa comunque abbastanza facile far funzionare il tutto:

this.PrintCommand = DelegateCommand.Create()
    .TriggerUsing( this.regionMonitor )
    .TriggerUsing( this.listChangedMonitor )
    .OnCanExecute( o =>
    {
        var canExecute = false;
        this.regionMonitor.TryGetViewModel<IPublicationListViewModel>( this.regionMonitor.ActiveContent, vm =>
        {
            canExecute = vm.SelectedItems.Count() == 1;
        } );

        return canExecute;
    } )
    .OnExecute( o =>
    {
        this.PrintSelection( this.actualPrinterSettings );
    } );

Ho già parlato sia di DelegateCommand che di trigger quindi vado al sodo… TriggerUsing() faceva una cosa del genere:

public IBindableCommand TriggerUsing( IMonitor source )
{
    source.Changed += onSourceChanged;
    return this;
}

adesso si è posto il problema che in quello scenario complesso questa dipendenza diretta porta, in alcuni casi, il GC a mordersi la coda.
Please welcome the “WeakEventManager”
La linee guida dicono di:

Creare una classe ad hoc, che eredita da WeakEventManager, ed è specilizzata per la gestione di un particolare evento: MonitorChangedWeakEventManager;
Implementare sul “gestore” dell’evento, in questo caso quindi il DelegateCommand, l’interfaccia IWeakEventListener;
Modificare il codice di “aggancio” dell’evento e passare la responsabilità al WeakEventManager di turno;

Partiamo quindi dal fondo, TriggerUsing() diventa:

public IBindableCommand TriggerUsing( IMonitor source )
{
    MonitorChangedWeakEventManager.AddListener( source, this );

    return this;
}

Non agganciamo più direttamente l’evento ma deleghiamo; per far si che comunque la notifica dell’evento arrivi da noi implementiamo l’interfaccia:

Boolean IWeakEventListener.ReceiveWeakEvent( Type managerType, object sender, EventArgs e )
{
    if( managerType == typeof( MonitorChangedWeakEventManager ) )
    {
        this.OnTriggerChanged( ( IMonitor )sender );
    }
    else
    {
        return false;
    }

    return true;
}

Questo è quanto: quando il WeakEventManager deve notificarci chiama ReceiveWeakEvent passandoci il tipo di manager, in modo da consentirci di prendere decisioni sulla base di chi sia il gestore, e passandoci i classici “sender” e “args”. Nostro compito è ritonare un Boolean che confermi o meno se l’evento ci è piaciuto… :-)
Il cuore del giochetto
Il tutto è gestito in maniera abbastanza semplice dal nostro manager specializzato:

public sealed class MonitorChangedWeakEventManager : WeakEventManager
{
    static MonitorChangedWeakEventManager GetCurrentManager()
    {
        var mt = typeof( MonitorChangedWeakEventManager );

        var manager = ( MonitorChangedWeakEventManager )WeakEventManager.GetCurrentManager( mt );
        if( manager == null )
        {
            manager = new MonitorChangedWeakEventManager();
            WeakEventManager.SetCurrentManager( mt, manager );
        }

        return manager;
    }

    public static void AddListener( IMonitor source, IWeakEventListener listener )
    {
        MonitorChangedWeakEventManager
            .GetCurrentManager()
            .ProtectedAddListener( source, listener );
    }

    public static void RemoveListener( IMonitor source, IWeakEventListener listener )
    {
        MonitorChangedWeakEventManager
            .GetCurrentManager()
            .ProtectedRemoveListener( source, listener );
    }

    private MonitorChangedWeakEventManager()
    {

    }

    void OnChanged( object sender, EventArgs args )
    {
        base.DeliverEvent( sender, args );
    }

    protected override void StartListening( object source )
    {
        var trigger = source as IMonitor;
        if( trigger != null )
        {
            trigger.Changed += OnChanged;
        }
    }

    protected override void StopListening( object source )
    {
        var trigger = source as IMonitor;
        if( trigger != null )
        {
            trigger.Changed -= OnChanged;
        }
    }
}

GetCurrentManager() sostanzialmente è un singleton e si appoggia a WeakEventManager per persistere la reference;
AddListener e RemoveListener sono i nostri entry point che delegano alla classe base l’operatività;
StartListening e StopListening vengono invocati dalla classe base per gestire il vero e proprio aggiancio/sgancio dell’handler;
Infine OnChanged, il nostro handler, utilizza il metodo DeliverEvent della classe base per dispatchare in maniera sicura l’evento;

Nulla di trascendentale, anzi alla lunga un po’ noiosetto da scrivere, ma per molte situazioni ottimo e risolutivo.
.m

Wpf, i tool e il bisogno di produttività…

2010-01-20T19:40:00.000+01:00

Secondo siamo ancora molto lontani dal vedere la luce. Il problema stavolta non è M-V-VM, come per ogni pattern di presentazione, imho, la produttività si misura nel lungo periodo mixando la produttività iniziale con la produttività del processo di manutenzione e di estensione.
Il problema di fondo è ancora il designer, quello di Visual Studio 2008 è pressochè inesistente mentre Blend se la cavicchia… ma proprio cavicchia. Non ho ancora avuto modo di stressare quello di Visual Studio 2010, ma da quel che sento in giro non farà di certo faville.
Cos’è che mi fa lamentare?
Il designer Windows Forms è ottimo ma probabilmente se ci ragioniamo quello che lo rende ottimo non è tanto il designer in se quanto il paradigma che ci sta intorno: Fixed Layout.
Flow Layout
Wpf introduce e spinge pesantemente, e per chi arriva dal mondo web in questo senso il salto forse è più facile, il concetto di Flow Layout e mano a mano che lo si usa ci si rende conto che adattare il layout al contenuto è cosa buona e giusta.
Questo però introduce un paio di problemi:

non potete più avere come strumento di design qualcosa di mediocre;
è fondamentale prototipizzare!

Per il secondo punto, a oggi per me, la carta è ancora lo strumento principe: facile, immediato, velocissimo… mi permette di raggiungere lo scopo, che è capire come organizzare le informazioni, in brevissimo tempo; per il primo punto invece siamo in altissimo mare… :-(
.m

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

2010-01-20T18:00:00.000+01:00

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 viene istanziata e ritornata dall’entry point;

Una cosa del tipo:

static class MyFluentEntryPoint
{
    public static FluentEngine Having( T value )
    {
        return new FluentEngine( value );
    }
}

e un engine così definito:

class FluentEngine
{
    readonly T value;

    public FluentEngine( T value )
    {
        this.value = value;
    }
}

Adesso per semplicità immaginiamo di voler essere in grado di fare 2 operazioni:

configurare l’engine appena creato;
mandare in esecuzione l’engine;

class FluentEngine
{
    readonly T value;

    public FluentEngine( T value )
    {
        this.value = value;
    }

    FluentEngine Configure()
    {
        return this;
    }

    FluentEngine Execute()
    {
        return this;
    }
}

Funzionare funziona ma incappate nel solito problema della “coding experience”:

Allora fate un secondo tentativo… fallimentare :-), almeno io ci sono incappato:

togliete il metodo Execute da FluentEngine;
create un ConfiguredFluentEngine:

class ConfiguredFluentEngine
{
    readonly T value;

    public ConfiguredFluentEngine( T value )
    {
        this.value = value;
    }

    public ConfiguredFluentEngine Execute()
    {
        return this;
    }
}

e cambiate la firma di Configure():

public ConfiguredFluentEngine Configure()
{
    return new ConfiguredFluentEngine( this.value );
}

funzionare funziona… avete risolto un problema e ve ne siete creati altri 2, figo:

se l’engine deve poter essere mandato in esecuzione anche senza la configurazione il metodo Excute lo dovete lasciare anche su FluentEngine pagando lo scotto di dover:
- o duplicare l’implementazione di Execute;
- o introdurre una terza classe per gestire l’esecuzione;
dovete preoccuparvi del mantenimento dello stato nel passaggio da una classe all’altra, e il nostro esempio è triviale in questo senso ma complicarsi la vita è moltissimo facilissimo;

Possiamo quindi asserire che non va bene :-) In realtà la soluzione è molto ma molto più semplice e l’abbiamo sotto gli occhi tutte le volte che usiamo una Fluent Interface fatta come si deve: interface… appunto :-)

Desiderata

Definiamo quello di cui abbiamo bisogno:

interface IConfiguredFluentEngine
{
    IFluentEngine Execute();
}

interface IFluentEngine
{
    IFluentEngine Execute();
    IConfiguredFluentEngine Configure();
}

e modifichiamo l’entry point di conseguenza:

static class MyFluentEntryPoint
{
    public static IFluentEngine Having( T value )
    {
        return new FluentEngine( value );
    }
}

A questo punto non ci resta che fare la cosa più banale di tutte: implementare tutte i contratti sulla stessa classe:

class FluentEngine : IFluentEngine, IConfiguredFluentEngine
{
    readonly T value;

    public FluentEngine( T value )
    {
        this.value = value;
    }

    public IConfiguredFluentEngine Configure()
    {
        return this;
    }

    public IFluentEngine Execute()
    {
        return this;
    }
}

garantendoci questo:

è ovvio che se complichiamo/estendiamo/necessitiamo di dare al developer una experience più corposa le cose si complicano e non di poco, ma il concetto resta sempre lo stesso: una singola classe che implementa contratti diversi, del resto la vostra necessità in questo caso è “semplicemente” ingannare l’intellisense :-)

Non è tutto… stay tuned.

Behavior vs Attached Property #2

2010-01-20T10:33:00.000+01:00

Vorrei sottolineare un’altra differenza non da poco tra Behavior e Attached Property, oltre a quelle di cui ho già parlato, e che Corrado nei commenti ha integrato.
Una Attached Property, in quanto proprietà, necessita che venga settato un valore al fine di “attivarla”, mentre un Behavior, in quanto comportamento, è molto più simile ad un metodo e, come evidenziato, non è necessario nulla perchè venga attivato:

<TextBox Height="23" Text="{Binding DataSource.StreetNumber}">
    <i:Interaction.Behaviors>
        <behaviors:DisableUndoManagerBehavior />
    i:Interaction.Behaviors>
TextBox>

Un discreto vantaggio :-)
.m

Atomicità: ad ognuno la sua :-)

2010-01-20T09:17:00.000+01:00

L’utente ha il suo concetto di atomicità, il developer ha il suo…
Utente 1 – Developer 0

L’utente crea un nuovo “Calendario”, poco importa cosa sia, diciamo che è un master-detail decisamente classico. Poi, dopo averlo creato, lo organizza come meglio crede e una delle cose che fa è rimuovere le pubblicazioni che non ci saranno, ad esempio quelle del mese di Agosto.
Quello che succede è:

Uno degli elementi viene rimosso dalla lista;
Tutti gli elementi successivi a quello rimosso vengono modificati per aggiornare, tra le tante, il “numero” dell’Uscita;

Poi… cambia idea e fa un bel sano “Undo” :-)
Quello che per noi sono n operazioni per l’utente corrispondono ad una sola operazione, quindi il livello di atomicità è diverso e naturalmente vince l’utente. Quindi il nostro memento deve supportare una cosa come questa:

[TestMethod]
public void changeTrackingService_atomicOperation_should_set_isChanged_only_on_operation_completed()
{
    var target = new ChangeTrackingService();

    var person = new Person( target );
    var list = new PersonCollection( target );

    using( var actual = target.BeginAtomicOperation() )
    {
        person.Name = "Mauro";
        list.Add( person );
        person.Name = "Mauro Servienti";

        target.IsChanged.ShouldBeFalse();

        actual.Complete();
    }

    target.IsChanged.ShouldBeTrue();
}

[TestMethod]
public void changeTrackingService_using_atomicOperation_should_fully_rollback_using_one_undo()
{
    var target = new ChangeTrackingService();

    var person = new Person( target );
    var list = new PersonCollection( target );

    using( var actual = target.BeginAtomicOperation() )
    {
        person.Name = "Mauro";
        list.Add( person );
        person.Name = "Mauro Servienti";

        actual.Complete();
    }

    target.Undo();

    list.Count.ShouldBeEqualTo( 0 );
    person.Name.ShouldBeEqualTo( String.Empty );
}

e naturalmente questa, un filino più complessa:

[TestMethod]
public void changeTrackingService_using_atomicOperation_redo_should_reapply_all_changes_with_one_pass()
{
    var target = new ChangeTrackingService();

    var person = new Person( target );
    var list = new PersonCollection( target );

    using( var actual = target.BeginAtomicOperation() )
    {
        person.Name = "Mauro";
        list.Add( person );
        person.Name = "Mauro Servienti";

        actual.Complete();
    }

    target.Undo();
    target.Redo();

    list.Count.ShouldBeEqualTo( 1 );
    person.Name.ShouldBeEqualTo( "Mauro Servienti" );
}

Tutti i test passano, e sono stati frutto della mia esternazione :-), il secondo è, per ora, frutto di un hack che mi piace decisamente poco, uno special case interno al motore di Change Tracking.
Utente 1 – Developer 1: palla al centro :-)
Questo però, fortunatamente o meno per voi :-), mi ha ricordato che abbiamo qualcosa in sospeso: date tempo al tempo ;-)
.m

Wpf TextBox.UndoLimit “sbomba” by design :-)

2010-01-20T08:35:00.000+01:00

… che a casa mia si chiama BUG, e come tale è riconosciuto.
Un po’ di storia
Se cercate di fare questo:

<TextBox UndoLimit="0" Text="{Binding DataSource.Zone, ...

con lo scopo di disabilitare il supporto per l’Undo offerto da Wpf, vi beccate una sonora exception “Cannot use UndoService while it is disabled”… l’inghippo è che quella cosa sbomba da paura a runtime se avete impostato un Binding sulla proprietà Text. Lo snippet qui sotto, grabbato con Reflector, spiega molto bene il problema:

Quella chiamata a Clear() scoppia perchè avete impostato UndoLimit a “0” disabilitando di fatto l’UndoManager.
Possibili Workaround
San Google propone una serie di possibili soluzioni:

(fonte)
Come lo stesso autore dice, non funziona :-), e ne propone un’altra:

Ma sinceramente a me non va neanche questa, nonostante in molti siano decisamente soddisfatti, non ho errori semplicemente non succede nulla.
Un terzo, fallimentare tentativo, è stato creare una Attached Property che impostasse l’UndoLimit dopo l’evento Loaded, perchè alla fine il problema sta proprio li, ma anche questo fallisce perchè in fase di Unload del controllo la proprietà Text viene resettata e quindi il codice cerca di fare nuovamente il reset (Clear()) dell’UndoManager.
Alla fine, partendo da un hint trovato sui Microsoft Forum, la pezza definitiva è questo Behavior:

public sealed class DisableUndoManagerBehavior : Behavior<TextBox>
{
    protected override void OnAttached()
    {
        base.OnAttached();

        var cb = new CommandBinding();
        cb.Command = ApplicationCommands.Undo;
        cb.CanExecute += ( s, e ) => e.CanExecute = this.AssociatedObject.IsFocused;
        cb.Executed += ( s, e ) => e.Handled = true;

        this.AssociatedObject.CommandBindings.Add( cb );
    }
}

che utilizzato così:

<TextBox Text="{Binding DataSource.Zone}">
    <i:Interaction.Behaviors>
        <behaviors:DisableUndoManagerBehavior />
    i:Interaction.Behaviors>
TextBox>

produce l’effetto desiderato, in realtà l’UndoManager non viene disabilitato ma semplicemente reso innoquo.
…e Wpf 4.0?
Funziona come si deve senza costringerci a fare i salti mortali, e il fido Reflector conferma:

Vi chiederete… perchè devi disabilitare il suppporto per l’Undo? perchè se avete un vostro motore per gestire il change tracking… ;-)
.m