Silverlight 4 + RIA Services: Ready for Business: Updating Data in the Client

To continue our series, let’s look at updating the data.  I have created a Plates.xaml page with very similar structure to the above.    For details on how I created this page, check out my PDC 09 demo walk through. 

Now let’s look at updating the Plate data..

First we will create some default “form” UI by dragging an entity from the datasources window in much the same way we did above. 

But before we create the UI, notice the order of the fields – it matches the order they will be generated in the UI. They are in alphabetic order, but that is not always what you want.  For example, I think Name should be first.

To address this, in the server project, open the DishViewService.metadata.cs file and add the Display attribute to the Name field of the Plate class.  While we are in there, “Number Updates” isn’t such a good name to use in the UI, so let’s update that as well to something more readable.

[Display(Order = 0)]
public string Name { get; set; }
[Display(Name="Update Count")]
public Nullable<int> NumberUpdates { get; set; }

Now, flipping back to the client project, we see Name on the top

and when we drop it on the form, we see Update Count.

Now we have a form, and it is already wired up to the same datasource as the grid.  So let’s add a button the save changes.

So let’s add a save button to the form

and wire up its Command property (this gets called when the button is pressed).

Now, we need to wire this up to the Submit command on the DomainDataSource.  So we use element-to-element binding.  Select the platDomainDataSource

Then select the path to the SubmitChangesCommand

You know you have the right, if the button gets disabled (even on the design surface.. after all, there are no changes to submit, right)?

Now, run it and see the results

Notice as you change selection in the grid, the details UI is automatically updated, no coded needed.  Also notice that the save button is disabled until there are changes that need to be submitted to the server..  Try adding a “Cancel” button?  to remove the local changes.  it is very easy to wire up to the RejectChangesCommand in the same way.

Now, let’s see about actually update the data in the database.   Set a break point in the  make edits to two different entities on the

Notice this update method get’s called twice once for each entity changed on he client. 

Now let’s add a little more logic to the update to handle some business logic

  1:         public void UpdatePlate(Plate currentPlate)
  2:         {
  3:             currentPlate.NumberUpdates++;
  4: 
  5:             var orginal = this.ChangeSet.GetOriginal(currentPlate);
  6: 
  7:             if (orginal.Price != currentPlate.Price)
  8:             {
  9:                 // add 1 dollar fee for changing price
 10:                 currentPlate.Price += 1; 
 11:             }
 12:         }

First line 3, we update the NumberUpdates count, then if the price of this menu item is changing, we add a one dollar fee.  Notice we can easily check to see if this value is changed from the prospective of this client by using the client’s original value… The client sends to the server the original value it got from the server when it was first loaded for any field that changed, is a key or marked as a concurrency token.  (This is a small tweak from the last release when *all* original values were sent back the server).    For example, on an update that only changes the Calorie count, inspecting the original value, we see:

If you wanted to include Price on any update, you need to mark it as a concurrency token. To mark an field as a concurrency token in entity framework, select the field in the designer and change the Concurrency Mode to “Fixed”

With this change the original value for price will always be sent to the server… this is only a tiny bit more expensive for most fields, so I recommend doing it whenever the business logic requires it.