Is it by design that you can only call a custom method when there are no changes? RRS feed

  • Question

  • For me a custom operation is something I want to be able to invoke at any time on the client and in any circumstance. The latter means I want to call the custom operation for a partially populated entity for instance. And I don't expect the entities to be saved automatically after invoking a custom operation. I think this is a key concept in the RIA-architecture, so getting it right in the v1.0 release of RIA Services is crucial imho.

    Maybe it's related to this bug http://silverlight.net/forums/t/117371.aspx, but the required SubmitChanges to activate a custom method operation makes me wonder what the thought behind the flow is.

    • is the custom operation meant for unchanged entity sets only? If so, it's hardly usable, since you would expect to be able to call the custom operation at any time even during the data entry process.
    • by calling SubmitChanges you expect the data to be saved as well. When you invoke a custom operation, the following methods are called:
      • DomainContext.SubmitChanges 
      • DomainContext.ValidateChanges, triggering all validations
        • Why can't I submit an invalid/incomplete entity for a custom operation?
          As long as I don't save the entity, not all constraints have to be satisfied.... And invoking a custom operation isn't a save.
        • Why is it validating at all, since none of the entity properties have been changed on the client?
        • DomainService.Submit
      • DomainService.AuthorizeChangeSet
      • DomainService.ValidateChangeSet (once again ;-)
      • DomainService.ExecuteChangeSet
      • now my custom method is called
      • DomainService.PersistChangeSet
        Why is persist changes called? Or is it called, but cancelled, since my Update-method isn't called. Or is this by coincidence, because the EntityChangeSet has no client side changed entities?
      • DomainService.Query(queryDescription, out int totalCount)
        I don't get why this method should be called for a custom operation.... I have a POCO domain service so no problems, but I would be worried when this is hooked up to an EF-provider or a L2S-provider.... It might hit the database.
      • DomainService.Count(IQueryable)
      • and we're back in the client with the changed entity, bound to the screen


    Friday, August 14, 2009 10:00 AM


  •  I too would like to send incomplete entities.

    Ex: Sending an object of type User: I don't want the client populating the Username property as it's being handled by the HttpContext anyway.

    To workaround this I have to put dummy data in my entity and then once it reaches the server, use the actual authenicated username from HttpContext. 

    Friday, August 14, 2009 1:22 PM