IEnumerable>, IBindingList, ITypedList e ICustomTypeDescriptor

• Ok: giusta al posto giusto;
• Pubblicata ma sbagliata;
  • posto sbagliato;
  • dimensioni sbagliate
  • colore – B/N
  • etc…
• Non pubblicata:
  • Colpa nostra: perchè?;
    • --> ripianificazione
  • Richiesta del cliente: perchè?;
    • --> ripianificazione
• Sospesa:
  • Scelta nostra: perchè?
  • Richiesta del cliente: perchè?
• etc…

public interface IAdvertisementReservation
{
    AdvertisementType Type { get; }
    AdvertisementPosition Position { get; }
    AdvertisementColor Color { get; }
    Double ModulesQuantity { get; }
    IPublication PublishQueue { get; }
    AdvertisementReservationStatus Status { get; }
}

La sorgente dati di quella cosa è una IEnumerable, non è una collection perchè l’impegnato è scolpito nella pietra.

• ReservationManagerViewModel:
  • IEnumerable:
    • IAdversisementReservation
    • EditStatus

1. Ultimamente ho detto che il rischio dei DTO è l’abuso di DTO, ergo passate la vita a scrivere DTO (onore al capo che ha coniato questa frase): questo è uno scenario in cui il gioco vale la candela tutta la vita;
2. Sempre ultimamente ho detto che “rimappare” IList su IList> costa un sacco e ha anche qualche magagna: come al solito non viviamo di dogmi e scenari abbastanza complessi, nel loro insieme, meritano soluzioni flessibili e sensate, anche se a prima vista costose;
3. Wpf I love you: se penso di dover realizzare la stessa cosa (la UI per l’edit) con Windows Forms potrei dire che sarebbe decisamente più facile imparare un dialetto cinese e poi pinagere in quel dialetto… oppure passare l’esistenza con la peggiore delle suocere :-), in casi come questo Wpf dimostra tutta la sua potenza e dimostra anche che la curva di apprendimento merita di essere affrontata perchè superato lo scoglio iniziale fate cose che con Windows Form/GDI avrebbero un costo pressochè inavvicinabile… cosa ci fate ancora li con una tecnologia legacy!?!?!?! ;-)

DataTable dt = …
myDataGrid.DataSource = dt;

• la DataSource è una DataTable:
  • rimappa la DataSource su DataTable.DefaultView e ricomincia… la DataView è ITypedList;
• La DataSource è ITypedList:
  • Chiama GetItemProperties() e qui viene il bello…;
• altrimenti se la DataSource è ICollection/Array cerca di capire quale sia il tipo degli item, analizzalo via reflection e costruisci le colonne;

ListChangedType.PropertyDescriptorAdded;
ListChangedType.PropertyDescriptorDeleted;
ListChangedType.PropertyDescriptorChanged;

<TextBlock Text="{Binding Path=PropertyName}" />

var query = new ReservationsByPublicationQuery( this.CurrentPublication );
var source = this.DataContext.GetByQuery<IAdvertisementReservation>( query );

var view = new EntityView<IAdvertisementReservation>( source.ToArray() );
view.AutoGenerateProperties = false;

view.AddPropertyMapping( "EditStatus", typeof( EditStatus ), obj =>
{
    var status = ( EditStatus )obj.GetCustomValue( "EditStatus" );
    if( status == null )
    {
        status = EditStatus.Undefined;
        obj.SetCustomValue( "EditStatus", status );
    }

    return status;
} );

view.AddPropertyMapping( "Confirm", typeof( ICommand ), obj =>
{
    var cmd = obj.GetCustomValue( "Confirm" ) as ICommand;
    if( cmd == null )
    {
        cmd = DelegateCommand.Create()
            .OnExecute( o =>
            {
                var val = ( EditStatus )obj.GetCustomValue( "EditStatus" );
                if( val == EditStatus.Undefined )
                {
                    obj.SetCustomValue( "EditStatus", EditStatus.Ok );
                }
                else
                {
                    obj.SetCustomValue( "EditStatus", EditStatus.Undefined );
                }
            } );
        obj.SetCustomValue( "Confirm", cmd );
    }

    return cmd;
} );

var query = new ReservationsByPublicationQuery( this.CurrentPublication );
var source = this.DataContext.GetByQuery<IAdvertisementReservation>( query );

var view = new EntityView<IAdvertisementReservation>( source.ToArray() );
view.AutoGenerateProperties = false;

• Filtri;
• Sort;
• Aggiunta, rimozione di elementi;
• etc.. etc..

view.AddPropertyMapping( "EditStatus", typeof( EditStatus ), obj =>
{
    var status = ( EditStatus )obj.GetCustomValue( "EditStatus" );
    if( status == null )
    {
        status = EditStatus.Undefined;
        obj.SetCustomValue( "EditStatus", status );
    }

    return status;
} );

var itemView = view.ElementAt( 0 );
view.SetCustomPropertyValue( "EditStatus", itemView, EditStatus.Ok );

view.AddPropertyMapping( "Name", typeof( String ), obj =>
{
    return obj.GetCustomValue( "Name" ) as String;
}, ( obj, value ) => 
{
    obj.SetCustomValue( "Name", value );
} );

<ItemsControl ItemsSource="{Binding Path=Items}">
    <ItemsControl.ItemTemplate>
        <DataTemplate>
            <StackPanel Orientation="Horizontal">
                <TextBlock Text="{Binding Path=EditStatus}" />
                <Button Command="{Binding Path=Confirm}" Content="Invoke Command" />
            StackPanel>
        DataTemplate>
    ItemsControl.ItemTemplate>    
ItemsControl>

• “Wrappare” ha molto senso se dovete montare molta logica intorno all’item/entity che state manipolando;
• Se avete a disposizione una implementazione di IBindingList iniettarci la logica per gestire le proprietà calcolate è abbastanza banale, è tutto il resto di IBindingList che non lo è per niente… e per cose semplici vale molto la pena di wrappare con delle proprietà “calcolate” come nell’esempio ottenendo lo stesso identico risultato, anche in termini prestazionali, ma scrivendo molto meno codice. E’ evidente che al complicarsi della logica l’ago della bilancia si sposta verso un vero e proprio “ViewModelWrapper”, lo dimostra la proprietà calcolata che espone il command, è fattibile ma comincia ad essere troppo complesso e anche poco leggibile quindi probabilmente poco manutenibile;

• IBindingList / IBindingListView;
• ITypeList;
• ICustomTypeDescriptor;
• IRaiseItemChangedEvents;
• ICancelAddNew;
• INotifyCollectionChanged;
• ICollectionView;