Add/Remove with DataForm and RIA Services

Note: The limitations discussed herein no longer apply once you get WCF RIA Services V1 SP1 Beta (or later). See Kyle McClellan's blog for more info.

Tom Beeby posted a topic on the RIA Services forums about adding a new entity via the DataForm buttons. Specifically, he pointed out a problem where the DataForm does not light up the Add/Remove buttons when bound to an EntityList from your DomainContext. To exacerbate the problem, it turns out that binding to an EntityCollection<T> from RIA Services won’t let you Add or Remove either. I’ve dug into this problem with some team members, and we’ve identified the cause of the problem.

To be clear, binding a DataForm and getting Add/Remove support works just fine when you’re binding to the DomainDataSource’s Data property. It’s only when you’re binding directly to the DomainContext that the buttons don’t light up.

It turns out that there’s nothing built into RIA Services to easily work around this problem right now. And we haven’t yet decided if/how we’ll address the issue in later releases. But I came up with a solution that people could use today. It comes with no warranties, no guarantees that it won’t kill your cat or cause you other sorts of pain. But from my limited testing, it seems to work for me.

If you want to skip the details, you can grab the solution source and binaries here – there’s another link at the bottom of the post.

When the DataForm is bound to a collection, it inspects the collection to see if it implements an interface that would support adding and removing items. If your collection implements IList, I’ve been told that the Add and Remove buttons will light up. Neither EntityList<T> nor EntityCollection<T> implement this interface. It wouldn’t make sense either, since EntityList and EntityCollection don’t really work in an index-oriented fashion and IList is index-centric. Fortunately, we have another option, and it’s what the DomainDataSource leverages. We can implement ICollectionView and IEditableCollectionView.

DataForm will check to see if the collection implements ICollectionView. If so, it will further check to see if the collection implements IEditableCollectionView. If it does, then your collection will be queried for CanAdd and CanRemove, and the interface will be used to drive the respective functions. To get DataForm to light up the Add and Remove buttons for your EntityList or EntityCollection, we just need to provide a collection that implements ICollectionView and IEditableCollectionView.

Okay, I lied, that’s not entirely true. We also need to implement IEnumerable, INotifyCollectionChanged, and INotifyPropertyChanged. Using my favorite Visual Studio editor shortcut, Ctrl+(dot), Enter, we can very quickly define our API and start filling in the methods and properties. But of course, we do have a slight problem: I wanted to provide a solution that works against the already-released July 2009 Preview of RIA Services, so we can’t just add this implementation into RIA Services. So instead, I’m going to provide a way to bolt this on. This requires a little binding trickery.

The idea is to create a wrapper class that will take either an EntityList<T> or an EntityCollection<T>, and provide the right interface implementations on top of what it’s given. Then, we’ll create a binding converter that will take the EntityList<T> or the EntityCollection<T>, and return a wrapper collection instance. We’ll call our wrapper collection an EntityCollectionView<T>, and our converter an EntityCollectionViewConverter.

A mere 500 lines of code into the exercise (I won’t bore you with the details of implementing all of the interfaces), I had a working EntityCollectionView<T> class, and I started to crank out the EntityCollectionViewConverter and immediately ran into a roadblock. Because my class is generic, but I don’t know my entity’s type at design time, I can’t construct the view instance very easily. Instinct was to make the view class non-generic, but that doesn’t work because there isn’t a non-generic type for EntityCollection, so my view type must be generic in order to work with EntityCollection<T>.

Building up the generic instance wasn’t very difficult though, using a couple of good friends: GetGenericArguments() and MakeGenericType().

/// <summary>

/// Factory for creating an <see cref="EntityCollectionView{T}"/> instance from an

/// <see cref="EntityList{T}"/>.

/// </summary>

/// <param name="entityList">The <see cref="EntityList{T}"/> to create a view from.</param>

/// <returns>

/// An <see cref="EntityCollectionView{T}"/> that wraps around the <paramref name="entityList"/>.

/// </returns>

public static IEditableCollectionView FromEntityList(EntityList entityList)

{

    Type listType = entityList.GetType();

    Type[] genericArgs = listType.GetGenericArguments();

  

  if (genericArgs.Length != 1)

    {

  throw new ArgumentException("entityList must be an EntityList<T>");

    }

  

    Type collectionViewType = typeof(EntityCollectionView<>).MakeGenericType(genericArgs.Single());

  return (IEditableCollectionView)Activator.CreateInstance(collectionViewType, entityList);

}

  

/// <summary>

/// Factory for creating an <see cref="EntityCollectionView{T}"/> instance from an

/// <see cref="EntityList{T}"/>.

/// </summary>

/// <param name="entityCollection">The <see cref="EntityCollection{T}"/> to create a view from.</param>

/// <returns>

/// An <see cref="EntityCollectionView{T}"/> that wraps around the <paramref name="entityCollection"/>.

/// </returns>

public static IEditableCollectionView FromEntityCollection(object entityCollection)

{

    Type collectionType = entityCollection.GetType();

    Type genericType = collectionType.GetGenericTypeDefinition();

  

  if (!typeof(EntityCollection<>).IsAssignableFrom(genericType))

    {

  throw new ArgumentException("entityCollection must be an EntityCollection<T>");

    }

  

    Type collectionViewType = typeof(EntityCollectionView<>).MakeGenericType(collectionType.GetGenericArguments().Single());

  return (IEditableCollectionView)Activator.CreateInstance(collectionViewType, entityCollection);

}

We can even add a single method that makes the decision between which factory method to call.

/// <summary>

/// Factory for creating an <see cref="EntityCollectionView{T}"/> instance from either

/// an <see cref="EntityList{T}"/> or an <see cref="EntityCollection{T}"/>.

/// </summary>

/// <param name="entityListOrEntityCollection">

/// Either an <see cref="EntityList{T}"/> or an <see cref="EntityCollection{T}"/>.

/// </param>

/// <returns>

/// An <see cref="EntityCollectionView{T}"/> that wraps around the <paramref name="entityListOrEntityCollection"/>.

/// </returns>

public static IEditableCollectionView From(object entityListOrEntityCollection)

{

    EntityList list = entityListOrEntityCollection as EntityList;

  

  if (list != null)

    {

  return FromEntityList(list);

    }

  else

    {

  return FromEntityCollection(entityListOrEntityCollection);

    }

}



These three methods have to exist in a non-generic type, so I created a static class for EntityCollectionView to house them. Now, we can write a very simple converter that will produce the EntityCollectionView<T> from an EntityList<T> or an EntityCollection<T>.

using System;

using System.Windows.Data;

  

namespace QuickSilverlight.RiaServices

{

  /// <summary>

  /// Convert an <see cref="EntityList{T}"/> or an <see cref="EntityCollection{T}"/> into

  /// an <see cref="EntityCollectionView{T}"/> that can be used for DataForm binding.

  /// </summary>

  public class EntityCollectionViewConverter : IValueConverter

    {

  public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

        {

  // Can't construct an EntityCollectionView<T> because we don't easily know the <T>.

  // Let this factory method do the work for us.

  return EntityCollectionView.From(value);

        }

  

  public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

        {

  throw new NotSupportedException("The EntityCollectionViewConverter does not support two-way binding");

        }

    }

}

Using the binding converter is a breeze:

  <UserControl.Resources>

    <qs:EntityCollectionViewConverter x:Key="EntityCollectionViewConverter" />

  </UserControl.Resources>

  ...

  <df:DataForm x:Name="OrderForm"

     ItemsSource="{Binding Path=CustomerContext.Customers, Converter={StaticResource EntityCollectionViewConverter}}" />

Binding to an EntityList directly off of the DomainContext works great. You get the Add/Remove buttons on the DataForm, and all edit operations and navigation operations work just fine.

I did notice that I’m not entirely handling the EntityCollection Master/Details scenarios, because when you Add or Remove, it only adds to and removes from the details EntityCollection and not the DomainContext itself. Without having access to the DomainContext, I don’t think I can make it do that. I’d love to hear thoughts on that scenario to see if it’s something I should work into this solution.

Source code and binaries available here:
QuickSilverlight.RiaServices.zip

I hope this helps, but any and all feedback is welcomed.