[WPF] Come litigare con INotifyPropertyChanged e vivere felici

Collegare una proprietà di una classe ad un elemento di WPF implementando INotifyPropertyChanged è facilissimo da fare (anche se verboso) quando abbiamo una nostra classe, ma diventa "un po' antipatico" in casi leggermente più complessi. Mi ci sono impuntato scrivendo una piccolissima applicazione di data logging che deve ricevere e registrare i dati provenienti da una bilancia via RS232.

DataLogger 

Per farla semplice: ho una classe Bilancia che ha un campo comPort di tipo SerialPort e una proprietà ComPort { get; }

Il problema nasce dal fatto che la classe SerialPort non è stata pensata per essere "WPF friendly" e non implementa INotifyPropertyChanged e questo mi crea problemi perchè vorrei bindare la TextBox relativa alla porta com utilizzata con il valore di bilancia.ComPort.PortName

Per risolvere la questione dovrei creare una classe che estende SerialPort, a cui far implementare l'interfaccia INotifyPropertyChanged ma lo devo fare wrappando la classe perchè non è possibile eseguire l'override del membro ereditato 'System.IO.Ports.SerialPort.PortName.get' visto che non è contrassegnato come virtual, abstract o override (copiato paro paro dal messaggio di errore di Visual Studio).

Per giunta, a rendere la questione ancora più ingarbugliata, c'è il post Is INotifyPropertyChanged an anti-pattern? di Neil Mosafi che è molto interessante e provocante, insieme al post INotifyPropertyChanged -- Searching for a Better Way di Jeff Handley.

Maremma scribacchina, non si finisce mai di studiare! Quando pensi di aver capito qualcosa e di poterlo applicare sempre e con facilità, giri l'angolo e trovi subito un caso d'uso che ti complica la vita.

[WPF] Ancora sul data binding two way

Prometto (e potrei essere vestito da marinaio...) che è l'ultimo post sull'argomento, ma googlando ho trovato nuova legna da mettere al fuoco.

Nei miei post precedenti

ho dato la mia opinione sul comportamento di WPF quando gestisce un binding two way tra una TextBox e la proprietà di una classe, in una particolare situazione (che non torno a descrivere visto che ci ho fatto sopra ben tre post!).

LudovicoVan mi ha "vivisezionato" e fatto letteralmente a pezzi (non fraintendetemi, lo ha fatto con cognizione di causa e in modo assolutamente lecito, non ho sofferto per nulla!) e io mi sono alfine arreso.

Ma ieri, googlando su binding e INotifyPropertyChanged (per un altro motivo, di cui tratta il mio prossimo post) mi sono imbattuto su un thread di discussione e un post che mi danno in parte ragione, e siccome sono arrendevole ma anche cocciuto (strano miscuglio), ve li cito:

Il thread è contenuto nel forum ufficiale di Microsoft, ed è interessante la risposta data da Sam Bent (MSFT dev lead for data binding) di cui riporto la prima parte: "I'm afraid we cannot change this behavior - it would be a breaking change (meaning it could break existing apps). [...]".

Il post è di Rockford Lhotka e spiega come risolvere il problema in modo molto elegante, mediante l'uso di un IdentityConverter (un IValueConverter che non fa nessuna conversione, restituendo il medesimo valore passato).

La mia personale opinione si trova a metà tra la posizione di LudovicoVan che considera la questione del tutto irrilevante e quella delle fonti citate, che lo trattano come un vero e proprio bug, come descritto nel mio terzo post.

Larga è la foglia, stretta è la via, dite la vostra che io ho detto la mia!

«novembre»
domlunmarmergiovensab
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456