Saving Record after serialization and deserialization

I have a domain model and am passing our a list of objects that were created by Data Access
​        public List<batch.dal.Profile> ReadProfiles()
        {
            using (var dbContext = new batch.dal.dbContext())
            {
                return dbContext.Profiles.ToList();
            }
        }


The record is then modified on the client and when I save it as below the record is duplicated. The database key is a GUID and I have verified that the GUID is intact before the add. When the below is run it creates a duplicate
​        [WebInvoke(RequestFormat = WebMessageFormat.Json, ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.WrappedRequest)]
        [OperationContract]
        public bool UpdateProfile(batch.dal.Profile profile)
        {
            using (var dbContext = new batch.dal.dbContext())
            {
               dbContext.Add(profile);
                dbContext.SaveChanges();
            }
            return true;
        }

If I find the record by the Guid and then set that instance to the updated record, the save it ignored, even when I use the make dirty call. The only way I can find to update the record is to find the original record and then move each field from one object to the other and then save changes.

Is there an easier way of sending a class out in a webservice getting it back and then saving the data?

Thanks
Randy

Hello Randy,

Thank you for contacting us.

Generally when working with Telerik Data Access and services it is recommended to make use of the Detach/Attach API. This API is very useful in a service scenarios for two primary reasons - it prevents the unnecessary serialization of entire graphs of objects and makes handling inserts and updates easier. In my answer I will go through the best practices for using the Detach/Attach API in services.

Operation Returning Entities
In a service operation which reads data from the database and then returns it, it is recommended to detach the result before returning it. This makes the retrieved objects separated from their managing context and therefore prevents triggering the lazy loading of navigation properties when the object is serialized. The following modification of the ReadProfiles method is an example:


Handling Updates and Inserts
Updating an existing entity or inserting a new one can be handled using the same technique. You can attach the persistent object passed to the service operation to the context and then call SaveChanges. Telerik Data Access will automatically determine whether the attached object is new or existing one and execute the appropriate operation when SaveChanges is called. Consider the following modification of the UpdateProfile method which illustrates this approach:

Please do note that it is still recommended to use separate service operations in order to handle updates and inserts.

These same approaches are used in the services generated by our Service Wizard. If you are interested seeing examples of Telerik Data Access working in a service scenarios you can check out our Samples Kit which contains samples for various service technologies.

I hope this helps. Feel free to get back to us should you have any more questions.

Regards,
Kristian Nikolov
Telerik