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
OpenAccess ORM is now
Telerik Data Access. For more information on the new names, please, check out the
Telerik Product Map.