Kurser och utbildning av IT-proffs och systemutvecklare

Note: This post is based on the WCF RIA Services VS 2008 PDC Beta and VS 2010 Beta 2 preview, changes can be done before the framework hits RTM.

I have seen questions about how to dynamically create search criteria when using WCF RIA Services and LINQ. So this post is about how you can dynamically create a criteria as a string on the client-side and pass it down to the server for execution.

There is a simple way to create a criteria on the client-side by using WCF RIA Services and LINQ and pass it down to the server for execution, here is an example:

var dx = new CustomerDomainService();

EntityQuery<Customer> query = from customer in dx.GetCustomersQuery()
                              where customer.Country == "Sweden"
                              select customer;

dx.Load<Customer>(dx.GetCustomersQuery());

The problem with the above code and LINQ is that LINQ is static. So if we need to dynamically create a criteria it will be hard.

If we for example have an advanced search form with several ComboBox(s) and also TextBox(s) etc. we want to create a query based on the user’s inputs. It will require a lot of code if we use LINQ and probably an ugly condition statement. Wouldn’t it be great if we could do something like this:

var dx = new CustomerDomainService();

string criteria = string.Format("Country = {0} and CompanyName = {1}", countryComboBox.SelectedItem, companyNameTextBox.Text);

dx.Load<Customer>(dx.GetCustomersQuery(criteria));

The above code will dynamically create a criteria based on the user’s input and pass it to the GetCustomersQuery.

The CustomerDomainService GetCustomers Query method will look something like this:

[EnableClientAccess()]
public class DomainService1 : LinqToEntitiesDomainService<NORTHWNDEntities>
{
    public IQueryable<Customer> GetCustomers(string criteria)
    {
          return this.ObjectContext.CustomerSet;
    }
}

As you may see the criteria isn’t used in the code, and if we want to use it we need to parse the criteria and that will require a lot of code to create different static LINQ queries based on criteria. But there is a solution, that is the point of this blog post ;)

We can use the LINQ Dynamic Query Library to solve the problem. To use the LINQ Dynamic Query Library we need to add “using System.Linq.Dynamic” namespace to our DomainService (this after we have the LINQ Dynamic Query Library). To get it you can simply downloaded the example Lib from one of the following links:

What I did to make it work was to add the Dynamic.cs (.vb) class from the example to my Web project. Then added the “using System.Linq.Dynamic” to get the extension method added to the Dynamic.cs (.vb) file to the IEnumerable<T> interface.

When this is done we will have an extended version of the Where extension method which will take a criteria as a string and parse it for us to a valid query.

Here is a simple example where I have created a criteria on the client-side as a string and pass it down to the DomainService, where I use the LINQ Dynamic Query Library:

CustomerDomainService.cs

[EnableClientAccess()]
public class CustomerDomainService : LinqToEntitiesDomainService<NORTHWNDEntities>
{
    public IQueryable<Customer> GetCustomers(string criteria)
    {
         if (!string.IsNullOrEmpty(criteria))
             return this.ObjectContext.CustomerSet.Where(criteria, new object[] { });

         return this.ObjectContext.CustomerSet;
    }
}

MainPage.xaml.cs

public partial class MainPage : UserControl
{
    public MainPage()
    {
       InitializeComponent();

       var dx = new CustomerDomainService();

       string criteria = "Country = \"Sweden\" and City <> \"Luleå\"";

       dx.Load<Customer>(dx.GetCustomersQuery(criteria));

       customersDataGrid.ItemsSource = dx.Customers;
    }
}

When using the LINQ Dynamic Query Library all strings need to be enclosed by “ “, so that is the reason why you see \”Sweden\”. To make the criteria more interesting I also added that the City property shouldn’t be “Luleå” (Luleå is a city far to the north in Sweden).

The LINQ Dynamic Query Library will also work on Linq To SQL etc.

Summary

By using the LINQ Dynamic Query Library we can now in a easier way dynamically create a criteria based on users options, for example on a advanced search form.

If you want to know when I post a new blog post on my blog etc, you can follow me on twitter: http://www.twitter.com/fredrikn

Note: The WCF RIA Services examples in this post is based on the WCF RIA Services PDC Beta for VS 2008 and VS 2010 Beta 2 Preview.

I have notice that a lot of developers are passing a lot of data over the wire, like they have forgot or don’t see the network between the client and the server. In this post I’m going to show how some solutions can be used to minimize the loading of data. I’m not going to mention about using techniques like GZIP compression with IIS to reduce the size, instead how to use the DataPager and also do aync. calls to load data on demand etc.

The following example uses WCF RIA Services and the well known Northwind database. The example also uses the LinqToEntitesDomainService to just passing DAL types directly to the client over the network, but all the examples will work fine even with DTO/”Presentation Model”.

Note: By using DTO instead or create a Entity Data Model for presentation purpose only,you can reduce the number of values passed to the client and also focus on the data that should be displayed by the current View, so no extra data is passed. Passing too much data that shouldn’t be displayed on the view can affect performance badly if the app has many users.

Here is the code of the DomainService:

[EnableClientAccess()]
public class CustomerDomainService : LinqToEntitiesDomainService<NORTHWNDEntities>
{
    public IQueryable<Customer> GetCustomerSet()
    {
        return this.ObjectContext.CustomerSet;
    }
}

It simply returns all the Customers located in the Northwind’s Customers table. The View has a DataGrid to display all the Customers and here is the XAML for the View:

<UserControl
       xmlns:data="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data"
       xmlns:controlsToolkit="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Toolkit"  ...>
  <Grid x:Name="LayoutRoot">

      <data:DataGrid x:Name="customersDataGrid"/>
      <controlsToolkit:BusyIndicator x:Name="busyIndicator"/>

    </Grid>
</UserControl>

Note: It’s a good practice to add some kind of ProgressBar while loading data, the reason is because all communications to the Server services are made asynchronous and we can’t predict how long time it will take to load the data.

In the example above the Silverlight 3 November 09 Toolkit’s BusyIndicator is used as an activity indicator.

This example don’t use the WCF RIA Services DomainDataSource control, instead code-behind to load the Customers, the DomainDataSource will be mentioned later in this post.

Here is the code-behind of the View:

public partial class MainPage : UserControl
{
     public MainPage()
     {
         InitializeComponent();
         this.Loaded += new RoutedEventHandler(MainPage_Loaded);
      }

      void MainPage_Loaded(object sender, RoutedEventArgs e)
      {

         var customerDomainContext = new CustomerDomainContext();

         busyIndicator.IsBusy = true;
         customerDomainContext.Load<Customer>(
               customerDomainContext.GetCustomerSetQuery(),
               lo => busyIndicator.IsBusy = false
               null);

         customersDataGrid.ItemsSource = customerDomainContext.Customers;

     }
 }

The code above will show the BusyIndicator before the Loading of Customers takes place, and will hide the indicator when the Customers is returned from the server by passing a callback to the Load method of the customerDomainContext. The customerDataGrid’s ItemsSource property is set to the customerDomainContext’s Customers property. A very simple example of binding a DataGrid with data, but there are several problems with the above code.

1) The DataGrid in Silverlight 3 can take some time to add all rows and update the UI. (As far as I know the DataGrid in Silverlight 3 will not asynchronous add the rows. In a future version of Silverlight the rows may be added asynchronous, haven’t yet confirmed if the DataGird in Silverlight 4 will do it).

2) There are a lot of data passed over the wire because all Customers and the properties of a Customer entity will be passed over the network from the server to the client. If this is a public application we can’t know what kind of bandwidth the different users have etc. Passing too much data can affect performance badly.

3) The users will probably never walk through all the Customers in the list, so what’s the reason to add them all to the DataGrid from start?

The following part of the post will take each three issues above and show different solutions to reduce the above problems.

How to solve the problem where the DataGrid will take some time to display all rows?

One simple way to make sure that not all rows will be added to the DataGrid is by using paging. With Silverlight 3 there is a DataPager control which can be used for paging. The following shows how a DataPager can be added to XAML and be used with a DataGrid:

<UserControl
     xmlns:data="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data" 
     xmlns:controlsToolkit="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Toolkit"  ...>
    <Grid x:Name="LayoutRoot">

        <Grid.RowDefinitions>
            <RowDefinition/>
            <RowDefinition/>
        </Grid.RowDefinitions>

        <data:DataGrid x:Name="customersDataGrid"/>
        
        <data:DataPager
            Grid.Row="1"
            PageSize="20"
            Source="{Binding ItemsSource, ElementName=customersDataGrid}"
            IsTotalItemCountFixed="True"
            VerticalAlignment="Top"/>

        <controlsToolkit:BusyIndicator
            Grid.RowSpan="2"
            x:Name="busyIndicator"/>

    </Grid>
</UserControl>

The DataPager will only work if its Source property is set to a PagedCollectionView, so the Customers added to the customersDataGrid ItemsSource property needs to be converted to a PagedCollectionView, this can be done by creating an instance of the PagedCollectionView and pass the Customers as an argument to the PageCollectionView’s constructor.

public partial class MainPage : UserControl
{
   public MainPage()
   {
      InitializeComponent();
      this.Loaded += new RoutedEventHandler(MainPage_Loaded);
   }

   void MainPage_Loaded(object sender, RoutedEventArgs e)
   {
      var customerDomainContext = new CusotmerDomainContext();

      busyIndicator.IsBusy = true;

      customerDomainContext.Load<Customer>(
           customerDomainContext.GetCustomerSetQuery(),
           lo => busyIndicator.IsBusy = false,
           null);

     customersDataGrid.ItemsSource = new PagedCollectionView(customerDomainContext.Customers);
   }
}

The above code will only make sure the DataGrid will show data a lot faster by not adding all rows at once to the DataGrid, but it will still pass all Customers to the client. Some users may not want the paging support, instead they want to have all the Customers listed in the DataGrid. I try to make them understand what kind of problems that can lead to and try to suggest some other solutions, for example by adding a filter to make sure to only list about 500 items, and add a TextBlock to the View with a text like this: “Total number of Customers is 500 out of 25 000 ….”, then make sure they use some kind of filter to load some specific Customers, for example maybe filter on Country and City etc, everything to reduce the number of data passed from the server to the client. With WCF RIA Services there is a DomainDataSource Control which can be used with the DataPager and can asynchronous load the Customers the current page is showing. No code-behind is needed when the DomainDataSource is used. The following is an example where the DomainDataSource is used with a DataPager:

<UserControl
    xmlns:riaControls="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Ria"
    xmlns:riaData="clr-namespace:System.Windows.Data;assembly=System.Windows.Controls.Ria"
    xmlns:data="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data" 
    xmlns:myData="clr-namespace:SilverlightApplication53.Web"
     ...>
    <Grid x:Name="LayoutRoot">

        <Grid.RowDefinitions>
            <RowDefinition/>
            <RowDefinition/>
        </Grid.RowDefinitions>

        <data:DataGrid
            x:Name="customersDataGrid"
            ItemsSource="{Binding Data, ElementName=dds}"/>

        <data:DataPager
            Grid.Row="1"
            PageSize="20"
            Source="{Binding Data, ElementName=dds}"
            IsTotalItemCountFixed="True"
            VerticalAlignment="Top"/>

        <riaControls:DomainDataSource
            x:Name="dds"
            AutoLoad="True"
            PageSize="20"
            LoadSize="30"
            QueryName="GetCustomerSet">
            <riaControls:DomainDataSource.DomainContext>
                <myData:DomainService1/>
            </riaControls:DomainDataSource.DomainContext>
            <riaControls:DomainDataSource.SortDescriptors>
                <riaData:SortDescriptor PropertyPath="CompanyName" />
            </riaControls:DomainDataSource.SortDescriptors>
        </riaControls:DomainDataSource>

    </Grid>
    
</UserControl>

By using the DomainDataSource LoadSize property, we can specify how many Customers that should be loaded at a time. The PageSize is used to specify the size of the Page, in this case the each page should display 20 Customers.

The solution by using the DomainDataSource control will solve the three problems mentioned earlier in this post. It will reduce the number of data passed to the client, it will also make sure the DataGrid will show the data much faster and if the users don’t need to see all Customers, they don’t need get all Customers loaded and added to the DataGrid. The only limitation is the use of a DataPager which some users may not want to use.

Another solution to minimize the data passed to the client can be to only get 20 Customers and add them to the DataGird, and when the user moves the DataGrid Scrollbar an asynchronous call is made to get the next 20 Customers and add them dynamically to the DataGrid. By doing so the DataPager isn’t needed and the DataGrid can show the Customers a lot faster, it will also reduce the number of Customers passed from the server to the client.

How to minimize the number of items passed over the wire?

The DomainContext’s Load method takes a Query as an argument, the Query will  be passed to the DomainService and will be executed on the server-side. So by using this Query feature we can make sure to filter the data and only make sure the Query method will give us the items we are interested in. The following example will create a Query and pass it down to the server for execution, the query will make sure to Skip a number of Customers and only take 21 Customers:

EntityQuery<Customer> query = _customerDomainContext.GetCustomerSetQuery()
                                                    .OrderBy(customer => customer.CompanyName)
                                                    .Skip(0)
                                                    .Take(21);

_customerDomainContext.Load<Customer>(
                                      query,
                                      lo =>
                                      {
                                          busyIndicator.IsBusy = false;
                                      },
                                      null);

To reduce the number of items passed over the wire and skip the use of a DataPager we can create our own Custom DataGrid where we will only show the 21 first Customers and when the user moves the DataGrid’s  Vertical Scroller we load the next 21 Customers asynchronous and add them to the DataGrid. The reason why we need to create our own custom DataGrid is because we will not have access to the Vertical Scroller from the DataGrid itself. The DataGrid will only add a Scroller if some items will not fit into the height of the DataGrid. If we only get 21 Customers and bind it to the DataGrid and they all will fit into the DataGrid no scroller will be visible, and the users will think they got all Customers. What we need to do is to add a Scroller as if all the Customers are already added to the DataGrid. To make sure to make such as Scroller we need to get the actual height of a DataGrid row and also get the total number of Customers the DataGrid should normally display, and take the height times the number of Customers to fake the Scroller. By using the WCF RIA Services service operation we can do a really fast call to get the total number of Customers, then we can create a Query to load a the 21 first Customers. You may wonder why 21 why not 20, the reason is that we will set the height of the DataGrid so only 20 items will be listed, but to get access to the Scroller and set a its range we need to make it appear. So a simple hack to get access to the Scroller is to just show 20 items but add 21 to the DataGrid. The following code is the new CustomerDomainService with a Service operation to get the total number of Customers:

[EnableClientAccess()]
public class CusotmerDomainService : LinqToEntitiesDomainService<NORTHWNDEntities>
{
    public IQueryable<Customer> GetCustomerSet()
    {
        return this.ObjectContext.CustomerSet;
    }

    [Invoke]
    public int NumberOfCustomers()
    {
        return this.ObjectContext.CustomerSet.Count();
    }
}

The following code is the code-behind of the View that will  show the Customers:

public partial class MainPage : UserControl
{
    CustomerDomainService _customerDomainContext = new CustomerDomainService();

    int _currentPage = 0;
    const int NumberOfItemsToLoad = 20;
        
    public MainPage()
    {
        InitializeComponent();
        this.Loaded += new RoutedEventHandler(MainPage_Loaded);
    }


    void MainPage_Loaded(object sender, RoutedEventArgs e)
    {
        customersDataGrid.ItemsSource = _customerDomainContext.Customers;
        LoadCustomers();
     }

     private void LoadCustomers()
     {
         busyIndicator.IsBusy = true;

         EntityQuery<Customer> query = _customerDomainContext.GetCustomerSetQuery()
                                       .OrderBy(customer => customer.CompanyName)
                                       .Skip(_currentPage * NumberOfItemsToLoad)
                                       .Take(NumberOfItemsToLoad+1);

         _customerDomainContext.NumberOfCustomers(
                     io =>
                     {
                        customersDataGrid.TotalNumberOfRows = io.Value;

                        _customerDomainContext.Load<Customer>(
                                       query,
                                       lo =>
                                       {
                                          busyIndicator.IsBusy = false;
                                       },
                                       null);
                     },
                     null);
    }


    private void customersDataGrid_LoadNewItems(object sender, 
System.Windows.Controls.Primitives.ScrollEventArgs e)
    {
       _currentPage++;
       LoadCustomers();
     }
}

I will not focus so much on this code, I assume you can figure out what it does. The NumberOfCustomers Service operation will be executed before loading the  Customers to make sure the custom DataGrid’s TotalNumberOfRows property is set before the Customers is added to the DataGird’s ItemsSource. You can also see in the code that the Skip and Take is used to create a Query, the _currentPage will be increased by 1 when the custom DataGrid will trigger its LoadNewItems event handler (The LoadNewItems event will be trigged when the Scroller of the DataGrid reach a specific value, in this case when 20 rows are displayed in the DataGrid and the next 20 must be loaded and added to the DataGrid). The LoadNewItems event handler will also make a call to the LoadCustomers method to Load the next 21 Customers. The following code is the XAML of the View where the custom DataGrid is used:

<UserControl
    xmlns:data="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data" 
    xmlns:controlsToolkit="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Toolkit"  
    xmlns:myData="clr-namespace:SilverlightApplicationSample"
    ...>
    <Grid x:Name="LayoutRoot">

        <myData:AsyncDataGrid
            x:Name="customersDataGrid"
            Height="505"
            LoadNewItems="customersDataGrid_LoadNewItems"
            />
        
        <controlsToolkit:BusyIndicator
            Grid.RowSpan="2"
            x:Name="busyIndicator"/>

    </Grid>
</UserControl>

The following code is the custom DataGrid:

public class AsyncDataGrid : DataGrid
{
    public event ScrollEventHandler LoadNewItems;

    private double _rowHeight = 0.0;
    private double _oldScrollValue = 0.0;
    private ScrollBar _verticalScrollBar = null;

    public AsyncDataGrid()
    {
       this.LoadingRow += AsyncDataGrid_LoadingRow;
    }

    public int TotalNumberOfRows { get; set; }

    private double GetNextLoadingPosition()
    {
       var numberOfItems = 0;

       foreach (var item in ItemsSource)
          numberOfItems++;

       return _rowHeight * numberOfItems;
    }

    public override void OnApplyTemplate()
    {
       base.OnApplyTemplate();

       _verticalScrollBar = this.GetTemplateChild("VerticalScrollbar") as ScrollBar;

       if (_verticalScrollBar != null)
         _verticalScrollBar.Scroll +=scrollBar_Scroll;
    }

    private void  AsyncDataGrid_LoadingRow(object sender, DataGridRowEventArgs e)
    {
       e.Row.SizeChanged += Row_SizeChanged;
       this.LoadingRow -= AsyncDataGrid_LoadingRow;
    }

    private void Row_SizeChanged(object sender, SizeChangedEventArgs e)
    {
       _rowHeight = e.NewSize.Height;
       ((DataGridRow)sender).SizeChanged -= Row_SizeChanged;

       if (_verticalScrollBar != null)
       {
          _verticalScrollBar.Maximum = TotalNumberOfRows * _rowHeight;
          _verticalScrollBar.UpdateLayout();
       }
    }

    private void scrollBar_Scroll(object sender, ScrollEventArgs e)
    {
      if (LoadNewItems != null && e.NewValue > _oldScrollValue)
      {
        _verticalScrollBar.Maximum = TotalNumberOfRows * _rowHeight;

        if (e.NewValue >= GetNextLoadingPosition())
        {
          _oldScrollValue = e.NewValue;
          LoadNewItems(this, e);
        }
      }
   }
}

By override the OnApplyTemplate method, we can get access to the DataGrid’s Default ControlTemplate’s VerticalScrollbar and hook up to the Scroller’s Scoll event. By using the LoadingRow event and then the SizeChanged on a DataGridRow we can get the height of the DataGridRow (I couldn’t figure out a simple way of doing it, because the LoadingRow event can’t be used to get the ActaulHeight of the row loaded, it’s to early and there is no Rows property to get the UIElement of the DataGrid’s Row, the only way to get a DataGridRow is by using the LoadingRow event). Within the SizeChanged event handler of the DataGridRow, the Maximum property of the Scroller is set to the TotalNumberOfRows times the height of the row, this will make sure the Scroller has a range that will make sure it looks like several of rows are added but they aren’t. Withing the Scoller’s Scroll event handler (scrollBar_Scroll) the LoadNewItems event will be trigged only if the Scroller reach a position when new Customers should be loaded.

Note: I haven’t take care of the key board events, if a user uses the keyboard to walk through all the Customers added and reach the 21 Customer, no Customers will be loaded, but it’s easy to add. I left it out in this example because the hard part is to figure out how to handle the Scroller.

This solution will solve the three problems mentioned earlier in this post. It will reduce the number of data passed to the client, it will also make sure the DataGrid will show the data much faster and if the users don’t need to see all Customers, they don’t need get all Customers loaded and added to the DataGrid.

Summary

This post covered  some solutions to minimize the data loaded form the server to the client, and also speed up the DataGrid. This was done by using the DataPager control, or the DomainDataSoure or to load Customers while the users moves a DataGrid’s Scrollbar.

If you want to know when I post a new blog post or just follow my me, you can follow me on twitter: http://www.twitter.com/fredrikn

Note: This is post is based on the WCF RIA Services Beta for VS 2008 and changes can be done before WCF RIA Services hits RTM.

There are several post on the forums about changing the default number of items passed passed from a DomainService to the client, so I decided to write a short blog post about how to configure the WCF Service of the WCF RIA Services. If you want to know how the WCF RIA Services adds default endpoints etc, you can take a look at my Deep Dive post.

Have the following in mind when creating your DomainService:

There is a wire between the server and the client, so be careful and not pass too much data over the wire. In a enterprise application, an app with a lot of users or low bandwidth it’s advisable to create a light weight class (Data Transfer Object) instead of instead of just passing a DAL type generated from Linq to SQL, Entity Framework or a domain entity. Only pass the data the View needs, this will reduce the number on data passed over the wire. I have helped a lot of customers lately which has major performance issue because they exposes DAL types or domain entities over the wire. There is a reason why for example WCF uses a 65kb message limit by default. It’s to make sure we open up our eyes and notice the network which bounds our client with the server.

If you really need to pass a lot of data over the wire, you may notice that you will get an exception when you have exceeded the default number of item which can be serialized. You can change the maxItemsInObjectGraph size by configuring the WFC RIA Services behavior in web.config, by default this value is 65536 items. By changing the size of how many items which can be serialized and deserialized, you can “register” your service and add a behavior configuration for your service:

<system.serviceModel>

  <!— ... -->  

  <services>
    <service name="SilverlightApplication.Web.MyDomainService"
             behaviorConfiguration="MyDomainService_BehaviorConfig">
    </service>
  </services>

  <behaviors>
    <serviceBehaviors>
       <behavior name="MyDomainService_BehaviorConfig">
         <dataContractSerializer maxItemsInObjectGraph="xxxxxx"/>
       </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

The Service element name is the “Namesapce.DomainServiceName”. You don’t need to change the MaxReceivedMessageSize of the binding, because by default it’s set to: 2 147 483 647 bytes.

Note: The examples in this blog post uses WCF RIA Services PDC Beta, and changes can be made in the future to the framework.

In several of my blog posts about WCF RIA Services I have used the Repository pattern to return an IEnumerable<T>, for example:

public class CustomerRepository : ICustomerRepository
{
     public IEnumerable<Customer> GetCustomers()
     {
           //...
     }
}

And in the DomainService:

[EnableClientAccess()]
public class CustomerService : DomainService
{
     private ICustomerRepository _customerRepository;

     public CustomerService(ICustomerRepository customerRepository)
     {
         _customerRepository = customerRepository;
     }

     public IEnumerable<Customer> GetCustomers()
     {
         //Use _customerRepository
      }
}

Here is the client-side code which Loads the DTO/”Presentation Model” into the DomainContext:

 var customerContext = new CustomerContext();

 customerContext.Load<Customer>(customerContext.GetCustomers());

The Load method takes a Query object as an argument, by doing so, it knows which method in the DomainService it should call to load the objects. We can on the client-side specify our own query and pass it down to the server, and WCF RIA Services will make sure the execution of the Query will take place on the server side, this will reduce the data passed over the wire to the client. BUT! There is a problem of using IEnumerable<T>. The query will take place on top of the IEnumerable<T>, which means that our Repository will return ALL customers from the database, and this can affect performance (I talked to a well known SQL Server MVP about retrieving too much data from the database, he told me that he never notice a problem of retrieving to much data from a database, there are other issues that can affect performance badly.). So in that case, we don’t need to be worry?! I still think we should try to avoid retrieving data we don’t need from the database.

How can we solve the above issue with IEnumerable<T>?

We can for example get the query passed down to our DomainService and pass it to our Repositories, in that case we can use it as a Query Object. We can get the Query information by overriding the Query method of the DomainService class. Another solution is to create our own Query Object and pass it to the server as an argument to the GetCustomers method or just simply use the IQueryable<T> interface.

How can IQueryable<T> be used?

When using Entity Framework or Linq To SQL etc, we can create a query, this query will only be executed when we tell it to, for example calling the ToList method, Single etc of the query object:

var customersQuery = from customer in myContext.Customers
                     where customter.Country == "Sweden"
                     orderby customer.CompanyName
                     select customer;

var results = customersQuery.ToList(); //Execute the query here

As long as we don’t execute the customerQuery, we can extend the query, when we are done we execute it. When WCF RIA Services uses the EF or L2S Domain Service classes, it will only return the query (in this case use the IQueryable<T>) and not a list of objects, so when we use the Load method and pass down a query, the query will extend the returned query, and then WCF RIA Services will invoke the query and  EF and L2S will turn the query into T-SQL and execute it against the database. In that way we can reduce the data returned from our database to the DomainSerivce.

This sounds great, let us always return IQueryable<T>!

But! and a big one, we can’t use this solution in a RIA where business logic should be on the server-side. In some cases we may need to perform some business logic based on the data retrieved from the database, in this case we need to execute the query before returning our data to the client. So in this case we need to use IEnumerable<T>. But (a lot of but here), if we don’t need to perform any business logic on the server-side before we return our objects to the client, we can use the IQueryable<T>, I think it’s a nice solution for small client/server apps. It requires that the objects we want to send to the client are well designed and with the View in consideration. If we use the IQueryable<T>, we can’t use the Repository pattern, instead we can use a Query provider. So the Repository turns into a query provider:

public class CustomerQueryProvider : ICustomerQueryProvider
{
     public IQueryable<Customer> GetCustomers()
     {
           //...
     }
}

The CustomerQueryProvider can for example use EF or L2S to return an IQueryable<T> of customers:

public IQueryable<Customer> GetCustomers()
{
    _myObjectContext.Customers;
}

The DomainService will look like this:

[EnableClientAccess()]
public class CustomerService : DomainService
{
     private ICustomerQueryProvider _customerQueryProvider;

     public CustomerService(ICustomerQueryProvider customerQueryProvider)
     {
         _customerQueryPrivider = customerQueryProvider;
     }

     public IQueryable<Customer> GetCustomers()
     {
         //Use _customerQueryProvider.GetCustomers()
      }
}

The reason why a Query Provider is used here, is to remove dependencies to a specific detail. Now we can have different Query Providers as long as they implements the ICustomerQueryProvider interface and the infrastructure used in the Query Provider supports the IQueryable<T> interface.

Summary

For small database driven RIA where almost not business logic is needed, we can get a lot of benefits of using the IQueryable<T> interface instead of the IEnumerable<T>. But in a enterprise RIA where business logic should take place on the server-side, the IEnumerable<T> can be a better choice. But it depends! There are so many factors that must be known before we can know which design will fit best.

If you want to know when I publish new blog posts, you can follow me on twitter: http://www.twitter.com/fredrikn

Note: The code example in this post uses Silverlight 4 PDC Beta and WCR RIA Services PDC Beta, so some changes can be made before RTM.

In my previous post I wrote about “WCF RIA Services and a guide to use DTO/”Presentation Model””, and mention that I will later write a blog post about using a ViewModel. In this post I will show you how you can create a ViewModel and use Silverlight 4 Commanding to use the MVVM pattern. In this blog post I will use Unity as my Dependency Injection framework to inject my Repository to the DomainService, to make this possible we need to create our own DomainServiceFactory, check out my “WCF RIA Services Unity DomainServiceFactory” for information about how to use Unity and Dependency Injection, because I will not cover it in this post.

Architecture and design in this post

The following figure will show you the architecture and design I often use when building Rich Internet Applications:

In this post the Service Layer will be a DomainService using WCF RIA Services, the Domain Model will be a very simple, just have a Customer entity and a CustomerRepository. The follow if a class diagram of the Customer entity:

The following code is the CustomerRepository interface:

  public interface ICustomerRepository
  {
     Customer GetCustomerByID(int customerID);

     void Update(Customer customer);
  }

Note: This post will not focus on how the ICustomerRepository is implemented, assume it used Entity Framework, Linq to SQL, nHibernate or ADO.NET etc. It’s not important to know in this blog post.

The following code is the Service Layer, where WCF RIA Services DomainService is used and where the ICustomerRepository should be injected:

 [EnableClientAccess()]
 public class CustomerService : DomainService
 {
      private ICustomerRepository _customerRepository;

      public CustomerService(ICustomerRepository customerRepository)
      {
          _customerRepository = customerRepository;
      }

      public CustomerDto GetCustomerByID(int customerID)
      {
          var customer = _customerRepository.GetCustomerByID(customerID);

          return MapCustomerToCustomerDto(customer);
      }

      public void UpdateCustomer(CustomerDto customer)
      {
          if (customerDto == null)
              throw new ArgumentNullException("customer");

          _customerRepository.Update(MapCustomerDtoToCustomer(customerDto));
      }
  }

As you may notice there is a mapping (translator) between the domain Entity Customer to CustomerDto (Data transfer object). If we have used WCF, we would map our domain entity to the DataContract. Frameworks like the AutoMapper could for example be used here instead of manual mapping. In a small Intranet application where the internal bandwidth is good and we don’t have a lot of business logic, we could simply use our Customer and by  pass the mapping. But it all depends on the application we are building, there are so many factors included before we can decide the proper design for our application. So this post is not showing any Silver Bullets, they aren’t any. The following is the code for the CustomerDto, some validation annotation is used on the DTO, when using a ViewModel this validation could instead be added as “real” code to the ViewModel, if we do so, the validation will be executed when we write a test against our ViewModel. But in this example code, I decide that I don’t need to include data rules as part of the test.

 public class CustomerDto
 {
     [Key]
     public int CustomerID { get; set; }

     [Required]
     [StringLength(32, MinimumLength=2)]
     public string FirstName { get; set; }

     [Required]
     [StringLength(32, MinimumLength = 2)]
     public string LastName { get; set; }

     public int Age { get; set; }
}

Note: I will use my own DomainServiceFactory to make sure ICustomerRepository will be injected when the CustomerService is created, you can read more about it here.

Now the serer-side and Service layer is completed we can leave it and continue with the client implementation where a ViewModel is going to be used and also Silverlight 4’s Commanding.

ViewModel

A ViewModel is a representation of the View but as a class. Think of the movie Matrix, they only saw a lot of characters moving on the screens, but by looking at them, they saw the world. Think of the ViewModel class as the characters and by looking at it we should see the View. The reason to use a ViewModel is separation of concerns, we don’t want to have logic added to the view. With this separation we could also write automated test to test our View even if the UI isn’t in place.

Here is a skeleton of the ViewModel where Commanding is used:

    public class CustomerViewModel : ViewModel
    {
        public CustomerViewModel()
        {
        }

        public string FirstName
        {
            get;
            set;
        }

        public string LastName
        {
            get;
            set;
        }

        public bool IsAdult
        {
            get;
        }

        public bool IsLoading
        {

           get;
           internal set;
        } 

        public ICommand Save
        {
            get;
        }
    }

The ViewModel represents a View which should display two Input fields for FirstName and LastName, and also a read-only checkbox if the Customer is an adult or not. The View should also have a Save button. The IsLoading is used to show or hide a BusyIndicator. Here is the UI of the View which will use the ViewModel:

The following is the XAML for the View, where no code-behind is needed, instead a ViewModel is added as a resource and the data binding feature is used to bind the View to the ViewModel:

<UserControl
xmlns:my="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Toolkit"
    x:Class="SilverlightApplication1.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:vm="clr-namespace:SilverlightApplication1.ViewModels"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">

    <UserControl.Resources>
        <vm:CustomerViewModel x:Name="customerViewModel"/>
    </UserControl.Resources>

    <Grid x:Name="LayoutRoot" DataContext="{StaticResource customerViewModel}">

        <my:BusyIndicator IsBusy="{Binding IsLoading}"></my:BusyIndicator>

        <TextBox Text="{Binding FirstName, Mode=TwoWay, NotifyOnValidationError=True}"  ... />
        <TextBox Text="{Binding LastNaem, Mode=TwoWay, NotifyOnValidationError=True}" ... />

        <TextBlock Text="First Name:" .../>
        <TextBlock Text="Last Name:" .../>

        <CheckBox IsChecked="{Binding IsAdult}" Content="Is Adult" .../>
    
        <Button Command="{Binding Save}" Content="Save" ... />
    
    </Grid>
</UserControl>

ViewModel implementation

You have probably notice that the CustomerViewModel inherits the ViewModel class, the ViewModel class implements the the INotifyPropertyChanged and INotifyDataErrorInfo. You can find the implementation of the ViewModel on my other post about INotifyDataErrorInfo class. In the CustomerViewModel constructor there is a call to the WCF RIA Services to get a specific Customer, because the operation is asynchronous we can’t know how long it will take before the Customer is loaded, so the IsLoading property is set to true to show the BusyIndicator. Here is the whole implementation of the CustomerViewModel:

  public class CustomerViewModel : ViewModel, ISaveableViewModel
  {
        CustomerContext _customerContext = new CustomerContext();
        CustomerDto _customerDto = new CustomerDto();

        bool _isLoading = false;

        public CustomerViewModel()
        {
            this.IsLoading = true;

            _customerContext.Load<CustomerDto>(
                               _customerContext.GetCustomerByIDQuery(10),
                               loadOperation =>
                               {
                                 _customerDto = loadOperation.Entities.SingleOrDefault();
                                 LoadingCompleted();
                               }, null);
        }


        public string FirstName
        {
            get { return _customerDto.FirstName; }
            set
            {
                if (_customerDto.FirstName != value)
                {
                    _customerDto.FirstName = value;
                    NotifyPropertyChanged("FirstName");
                }
            }
        }


        public string LastName
        {
            get { return _customerDto.LastName; }
            set
            {
                if (_customerDto.LastName != value)
                {
                    _customerDto.LastName = value;
                    NotifyPropertyChanged("LastName");
                }
            }
        }


        public bool IsLoading
        {
            get { return _isLoading; }
            internal set
            {
               _isLoading = value;
               NotifyPropertyChanged("IsLoading");

            }
        }

        
        public bool IsAdult
        {
            get { return _customerDto.Age >= 18; }
        }


        public ICommand Save
        {
            get { return new SaveCommand(this); }
        }


        internal void SaveCustomer()
        {
            _customerContext.SubmitChanges();
        }

   




        private void LoadingCompleted()
        {
            NotifyPropertyChanged("FirstName");
            NotifyPropertyChanged("LastName");
            NotifyPropertyChanged("IsAdult");
            this.IsLoading = false;
        }
 }

Note: The above CustomerViewModel is not designed for testability, if we want to write a unit test to test the ViewModel, we could for example pass a DomainClient to the CustomerContext constructor when it’s created, it can be done in several ways, one way is for example to pass the DomainClient as an argument to the CustomerViewModel constructor, but then we have to use code-behind to create the CustomerViewModel or adding our own AttachedProperty. We can also add a DomainClient as a resources in XAML and use property injection to inject the DominContext to the ViewModel.

Something that may seems strange is the empty CustomerDto assigned to the _customerDto field. The other properties in the CustomerViewModel will access the _customerDto and its properties. To avoid adding a lot of if statements to check for null in both the get and set, a default CustomerDto is used. So it’s only a “ugly” hack to avoid a lot of code in each property. The load operation of a Customer will take place in the default constructor of the CustomerViewModel:

public CustomerViewModel()
{
   this.IsLoading = true;

   _customerContext.Load<CustomerDto>(
             _customerContext.GetCustomerByIDQuery(10),
             loadOperation =>
             {
                  _customerDto = loadOperation.Entities.SingleOrDefault();
                  LoadingCompleted();
             }, null);
}

The IsLoading property is set to true to make sure the BusyIndicator will be displayed when the loading takes place. When the loading of the Customer is completed the _customerDto will be set to the loaded customer and the LoadingCompleted method will be called. This method will make sure the BusyIndicator will be hidden and also notify the View about changes, so the bindings to the controls will call the get methods of bounded properties to get the loaded customer’s information and show it. The last part to cover is the use of Commanding in Silverlight 4.

Commanding

You can read about Commanding in my post “Silverlight 4 Commanding enables ViewModels”. In the ViewModel there are one method SaveRule, this is from the interface ISaveableViewModel implemented by the CustomerViewModel. There is also a Save property added to the CustomerViewModel, this property will return a SaveCommand where the ViewModel is passed as an argument.

public ICommand Save
{
    get { return new SaveCommand(this); }
}

internal void SaveRule()
{
     _customerContext.SubmitChanges();
}

The Save property is bounded to the View’s Save button’s command property. Here is the implementation of the SaveCommand returned from the Save property:

public class SaveCommand : ICommand
{
    private ISaveableViewModel _view;

    public SaveCommand(ISaveableViewModel view)
    {
        _view = view;
    }

    public bool CanExecute(object parameter)
    {
       return true;
    }

    public event EventHandler CanExecuteChanged;

    public void Execute(object parameter)
    {
        _view.SaveRule();
     }
}

As you can see the SaveCommand takes a ISaveableViewModel interface (Yes I know the name of the interface may be strange, but I’m not so good at naming ;)). The idea is to make sure the operation the Command should execute is added to the ViewModel itself, by doing so the Command can be reused by several other Views.

Summary

This post was about giving you the ideas of how you can use WCF RIA Services, the Model View View Model pattern and Commanding. The code used in this example is not perfect, no specific error handling was added more than using the WCF RIA Services validation annotation.

If you want to know when I publish a new blog post, then follow me on twitter: http://www.twitter.com/fredrikn

NOTE: Examples in this blog post is based on the VS 2010 Beta 2, WCF RIA Services PDC Beta, some changes to the WCF RIA Services can happen until RTM.

I have seen several questions and request about how to use Data Transfer Objects (DTO), or a ”Presentation Model” (Model created for presentation purpose) with WCF RIA Services. In this post I will write something about it.

Why use DTO/”Presentation Model”?

Why use DTO/”Presentation Model” at all? Well, domain entities aren’t design with presentation in mind; they are design to solve business problems. Because of that a domain entity is not created with presentation in mind and shouldn’t be passed to the View. If we do it, we will end up with a lot of logic in our view only to make sure our view will show the domain entities in the way we wants, and it can also ends up that we send more data than a view is needed. So with a DTO/”Presentation Model” we can create a new “model” with is designed with presentation in mind, and also will only contains the data the View needs.

My Windows to my logic

If we have a domain model in place or a simple n-tier architecture with a business logic layer and data access layer, we need to add a Service layer on top of them, and this layer is designed and created for our client in a Rich Internet Application only. The Service Layer will be our window to our logic. It’s the Service layer responsibility to communicate to our domain model or business logic, it also has the responsibility to only pass the data a client needs. This kind of data passed to the client is a DTO/”Presentation Model”. The Service layer knows about the domain model and also the DTO/”Presentation Model”. The domain model doesn’t know about the Service layer. The client/view or should I say “presentation layer” will only know about the existents of the Service layers and its services it will use, and also the DTO/”Presentation Model”, it will not know about the domain model.

The above figure shows how I often design my RIA. But and a big BUT, I select the design which is best suited for the application I’m building. If you take a look at the figure above, you can see that the “DTO/PM” is also known to the View, this is not always the case, which is why there is a box which will stop at the ViewModel. I have seen several articles and blog post where they say they use a ViewModel, but what they do is to pass the DTO directly to the View for rendering. Is that wrong? I will not say it is, instead say “It depends”. If our DTO/”Presentation Model” is well designed for a specific View, it is ok to pass it along through a ViewModel, but if it isn’t, it’s not ok. The ViewModel in this case is similar to Martin Fowlers Presentation Model pattern. Some developers still uses code-behind and no ViewModel, so in that case the View will use the DTO.

Note: In this post I will not use the ViewModel, I will just simply use code-behind to call the Service layer, this post is only about how we can use DTO/”Presentation Model” with WCF RIA Services. If you want to read more about RIA Architecture etc, you can check our the following blog post: http://weblogs.asp.net/fredriknormen/archive/2009/04/19/ria-architecture-with-silverlight-in-mind.aspx

Creating a Service Layer with WCF RIA Services using DTO/”Presentation Model”

Before creating the Service Layer, we will take a look at the Entity I have in my domain model.

The following is the View which should display the Customer:

As you can see the View and the Customer entity are very different. If we pass our Customer to the View, we need to add logic which will combine the FirstName and LastName property, and also add logic which will check the checkbox Is Adult, if Age >= 18 (In Sweden you are an adult it you are 18 years old ). The View is not interested in the Address, Phone property, so why pass it to the View? So what we can do is to create a DTO/”Presentation Model” for the View. We can add this model in a separate class library or to the Web projects which will host our Silverlight application. In a small application I often only create a folder in my Web project called “PresentationModel” and put my DTO/”Presentation Model” classes to that folder. The reason I do that is because the DTO/”Presentation Model” I will create is only for my Silverlight application, not for other clients. Here is my DTO/”Presentation Model”:

public partial class CustomerPM
    {
        [key]
        public int CustomerID { get; set; }

        public string FullName { get; set; }

        public int Age { get; set; }
    }

Note: I will make the DTO/”Presentation Model” partial, the reason I do that is to make it possible to use the WCR RIA Services .shared feature.

The DTO/”Presentation Model” should only pass the data the view is needed, nothing more. The CustomerID is marked with the KeyAttribute, and we must at least mark one property to be a identifier of the object. WCF RIA Service’s DomainContext has an Identity Map, and it will cache objects based on the specified key. The View will check a CheckBox if the Customer is an adult. We can pass the Age along to the View and use a ViewModel to add the logic to know if the Customer is and adult or not, but in this case we will not use a ViewModel (I do prefer a ViewModel), we instead turn the DTO into a “Presentation Model” instead. So we will use the .shared feature to add an IsAdult property. A DTO will not have any kind of logic, it will only be used to pass data over the wire, so if we add logic to a DTO, it will instead be something else, and in this case I will say it will be a “Presentation Model”, a model used to simply the presentation of an domain entity. Here is the .shared code for the CustomerPM:

CustomerPM.shared.cs:

    public partial class CustomerPM
    {
        public bool IsAdult
        {
            get { return this.Age >= 18; }
        }
    }

Now when the “Presentation Model” is created we need to create our Service Layer. The Service Layer in this case is the WCF RIA Services DomainSerivce, so here is the DomainService which will use the “Presentation Model”:

    [EnableClientAccess()]
    public class CustomerService : DomainService
    {
        private ICustomerRepository _customerRepository;


        public CustomerService()
        {
            _customerRepository = new CustomerRepository();
        }


        public CustomerService(ICustomerRepository customerRepository)
        {
            _customerRepository = customerRepository;
        }

        public CustomerPM GetCustomer(int customerID)
        {
            var customer = _customerRepository.GetCustomerByID(customerID)
            return new CustomerPM()
                   {
                      CustomerID = customer.CustomerID,
                      FullName = customer.FirstName + " " + customer.LastName,
                      Age = customer.Age
                   };
        }
    }

As you can see a WCF RIA Services query method can return a simple object, in this case the CustomerPM. The Query method will make a call to our domain model to get the Customer entity.

Note: In the current WCR RIA Services PDC beta for VS 2008, you can’t return a single entity, but it can be done in the VS 2010 version.

The CustomerRepository’s GetCustomerByID method can use Entity Framework, Linq To SQL, nHibernate or normal ADO.NET etc to fill a Customer entities with data from a data source.

By using Object Initializer we can simply map our domain entity to our “Presentation Model”. Normally I will do some refactoring here, and create a MapCustomerToCustomerPM method, which will handle the mapping. As you can see the CustomerService will take a ICustomerRepository as an argument to the constructor, this constructor can be used when we write unit test to test the DomainService. The default constructor will create a “real” instance of the CustomerRepository. Normally I would use a Dependency Injection framework, like Unity or StructueMap etc, can also use MEF (which is not a “pure” DI framework) to inject a ICustomerRepostiroy when the DomainService is created, to make that possible when using WCF RIA Services, we can for example create our own IDomainServiceFactory, I prefer my own IDomainServiceFactory instead, I will post a blog post about that later.

Now when our DomainService is in place we can now use it from our Silverlight application.

Calling our DomainService from Silverlight

WCF RIA Services will generate classes for us on the client-side, it will create a state-full context class for us (DomainContext), which will have Dirty tracking, Unit or Work and a Identity Map, we will use that class to load our entities into the context. The name of the DomainContext will be CustomerContext. WCR RIA Services will take the name of the DomainService when it creates the DomainContext, if the name has the suffix “Service”, it will rename it to “Context” on the client-side, if not it will keep the name of the DomainService. The following code will make an asynchronous call to our DomainService and get a specific customer and set the LayoutRoot’s DataContext to the CustomerPM and use data-bounding:

var customerContext = new CustomerContext();

            customerContext.Load<CustomerPM>(customerContext.GetCustomerByIDQuery(10),
                                            loadOperation =>
                                            {
                                                LayoutRoot.DataContext = loadOperation.Entities.First();
                                            }, null);

Here is the XAML:

<UserControl x:Class="SilverlightApplication1.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006">
  <Grid x:Name="LayoutRoot">

        <StackPanel>
            
            <TextBox Text="{Binding FullName}"></TextBox>
            <CheckBox IsChecked="{Binding IsAdult}"></CheckBox>
            
        </StackPanel>
      
  </Grid>
</UserControl>

Summary

As you may notice in  this blog post, it’s quite easy to use DTP/”Presentation Model”, if we want to add validations to our DTO/”Presentation Model”, we can simply do that with annotation.

If you want to read more about DTO/”Presentation Model” you can take a look at the following posts:

http://weblogs.asp.net/fredriknormen/archive/2009/11/20/wcf-ria-services-and-dto-with-association.aspx

http://weblogs.asp.net/fredriknormen/archive/2009/11/20/wcf-ria-services-what-you-need-to-know-when-creating-dto-presentation-model.aspx

If you want to know when I have published a new blog post, you can follow me on twitter: http://www.twitter.com/fredrikn

Note: This post is based on the WCF RIA Services PDC Beta.

There is a discussion about WCR RIA Services and how to update an EntitySet after a Submit changes, on the Silverlight forum. If we loads a set of entities they will be cached in an EntitySet on the client-side, so after a Submitting changes only the entities we have removed on the client will be removed from the client-side’s EntitySet. If someone else have removed some of the entities from the database we work against, we still have those cached on the client-side. At the moment there aren’t any reload features added to the WCF RIA Services, so we need to handle it by our self. We can’t just make a new call to the Load method of our DomainContext, it will only “merge” the existing EntitySet with changes or add new entities, but not removing anything. So what we need to do, is to implement code which will handle the removing of entites from the EntitySet. Here is an example code which will make sure removed entities (entities which is cached since an early Load operation but not part of the new Load operation) will be removed from the cached EntitySet:

_domainContext.SubmitChanges(
     submitOperation =>
     {
        _domainContext.Load<Customer>(
             _domainContext.GetCustomersQuery(),
              LoadBehavior.RefreshCurrent,
              loadOperation =>
              {
                 var results = _domainContext.Customers.Where(
                         entity => !loadOperation.Entities.Contains(entity)).ToList();

                 results.ForEach( enitity => _domainContext.Customers.Detach(entity));
              }, null);
      }, null);

The above code will after a SubmitChanges Load new entities from the server. The LoadBehavior is set to RefreshCurrent, it will make sure to refresh the current entities in the cached EntitySet, but will not remove anything. When the Load operation is completed and we got the new entities from the server, we then need to get the entities which is not part of the last Loading from the cached EnitySet:

var results = _domainContext.Customers.Where(
                         entity => !loadOperation.Entities.Contains(entity)).ToList();

Then we need to Detach the entities from the EntitySet. We can’t use the Remove method of the EntitySet, it will only mark entities for deletion. But the Detach method will not mark them and just remove them form the EntityList.

results.ForEach( enitity => _domainContext.Customers.Detach(entity));

We could also just clear the EntitySet buy setting using its Clear method before calling the Load method, but if we have bound the EntitySet to a data-bound control,the control will be notified when the EntitySet is cleared. That will make it “blink”. With the above solution there will not be any blinking.

I will not take all the credits for the solution in this blog post, I will thank Colin Blair for the basic ideas of removing entities from the EntitySet. In the future I hope we will se some other solution with less efforts.

If you want to know when I publish a new blog post, you can follow me on twitter: http://www.twitter.com/fredrikn