4

I am building an application based on Ria Services.

Amongst the default methods that were built by the Visual Studio Wizard, I can see the ones that should insert and persist new data.

For example:

    public void InsertCustomer(Customer customer)
    {
        if ((customer.EntityState != EntityState.Detached))
        {
            this.ObjectContext.ObjectStateManager.ChangeObjectState(customer, EntityState.Added);
        }
        else
        {
            this.ObjectContext.Customers.AddObject(customer);
        }
    }

However, I don't see any this.ObjectContext.SaveChanges(), which I read should be invoked in order to insert the entity in the data store. ...do I need to modify these functions in order to persist the information?

Thanks in advance, Cheers, Gianluca.

Anthares
  • 1,041
  • 1
  • 13
  • 30

2 Answers2

4

When you call SubmitChanges on the client, it calls into DomainService.Submit on the server. The default implementation then sequentially calls into a number of protected virtual methods including AuthorizeChangeSet, ValidateChangeSet, ExecuteChangeSet, and PersistChangeSet. Your CUD operation will be invoked from ExecuteChangeSet and ObjectContext.SaveChanges() will be invoked from PersistChangeSet.

You don't need to modify the default methods to persist information as that will be taken care of by default. However, the design gives you the option of overriding chunks of the submit pipeline if you find more complex scenarios necessitate it.

Kyle McClellan
  • 2,019
  • 1
  • 13
  • 8
  • 2
    Hi Kyle, thanks for your reply. Can I create a method on the Domain Service that performs multiple tasks (e.g. creates several new objects) and persist the new entities? And if I create this method "on the server", what happens if a client creates a new entities and invokes SubmitChanges? What happens if the server-side method is called after the client created the new entities, but before it invokes SubmitChanges? Do the client's newly-created entities exist only on the client-side until SubmitChanges is called? – Anthares Feb 15 '11 at 17:34
  • If you write an Invoke method to create several new objects, you will have to explicitly persist them (Invoke methods execute outside the Submit pipeline). If you write a CUD operation (for instance, creating entity A creates child entities B, C, and D) it will persist the changes for you. – Kyle McClellan Feb 15 '11 at 19:32
  • If entities are created on the server-side, you will have to re-query the server to pull them to the client. – Kyle McClellan Feb 15 '11 at 19:33
  • Entities created on the client only exist on the client until SubmitChanges is called. If you use an invoke operation to create entities on the server it will not also submit the changes that are pending on the client. – Kyle McClellan Feb 15 '11 at 19:35
  • @Kyle: Thank you so much for your answers and your patience. I still have one question. Let's say that on the service-side, in my domain service, I created a method CreateOrder(string code). Let's assume I perform all operations via ObjectContext, and I call ObjectContext.SaveChanges() at the end to persist my new entities and/or changes. How are clients notified about the new entities? Will I have to call explicitly Load.. at client-side? And how can I know that something changed in the server? I am getting lost in this... Thanks once again for your help. – Anthares Feb 16 '11 at 11:40
  • @Kyle: To clarify: unfortunately there are a series of operations that I cannot execute client-side. They must be executed on the server-side when a certain domain service method is called. These operations need to alter (create/update/delete) some data and persist them just in one go. At the end I'll end up with new entities on the server-side, and I am worried when you say that I need to requery the server, as many clients could be connected at the same time, and as far as I understood I should force them to reload all entities in use... which would be a pain... :/ – Anthares Feb 16 '11 at 11:45
  • The clients are not notified of the new entities and you will have to explicitly load them from the client. The feature you are really interested is the #1 request on the RIA wish list (http://dotnet.uservoice.com/forums/57026-wcf-ria-services). – Kyle McClellan Feb 16 '11 at 16:35
  • You have a few options when it comes to refreshing client data. A full refresh is probably the easiest and most reliable. However, you could also poll for new entities and pass a UTC time into the server (something like GetNewEntities(DateTime lastCheck)) to compare against the time an entity was created. There are a lot of different ways to approach this, but for now they all require calling from the client to server. – Kyle McClellan Feb 16 '11 at 16:39
0

What you should do is something like this:

//Create an instance of your Domain context in your class.
YourDomainContext context = new YourDomainContext();

if (context.HasChanges)
{
    context.SubmitChanges(so =>
        {
            string errorMsg = (so.HasError) → "failed" : "succeeded";
            MessageBox.Show("Update " + errorMsg);
        }, null);
}
else
{
    MessageBox.Show("You have not made any changes!");
}

Please take a look a this at this article: Using WCF RIA Services Or take a look at this video: Silverlight Firestarter 2010 Session 3 - Building Feature Rich Business Apps Today with RIA Services

Ramón García-Pérez
  • 1,880
  • 2
  • 20
  • 25
  • @BBHours: First of all, thank you for your reply. I understand from what you say that I should not modify my Domain Service methods, instead I should handle the "SubmitChanges" on the client-side. Is that right? If so, how should I handle the Domain Service methods that should immediately persist some information? Can I call there "ObjectContext.SaveChanges();"? And by doing so, do I risk to write in DB someone else's data? e.g. two clients connected to the same service.. thank you once again. – Anthares Feb 15 '11 at 14:36
  • When the **SubmitChanges** method is called, the DomainContext assembles a change set for all of its tracked entities and sends it to the corresponding DomainService. The DomainService then decomposes the change set and calls the respective domain operation for each entity that was inserted, updated, or deleted. So that said in the server side the DomainService knows what to do when you call SummitChanges in the client. I hope this can help you. Regards from Dominican Republic! – Ramón García-Pérez Feb 15 '11 at 15:21
  • Ok.But I'd like to implement a method in the domain svc (server-side) that performs a series of tasks:e.g. creates a customer, creates an account,etc.In practice, it should persist different entities in different tables.I wouldnt like the client to call several methods, instead I'd like it to make just one call and the domain svc to do whatever it is necessary.That's why I was asking if I can call SaveChanges() from the "server-side".However I am worried about what happens if_other_ clients call the same or other methods.On the domain svc, is created a context for each client, or is it global? – Anthares Feb 15 '11 at 16:21