This is a migrated thread and some comments may be shown as answers.

Fetch Strategy does not prevent Serialization of Navigation Properties

1 Answer 26 Views
Data Access Free Edition
This is a migrated thread and some comments may be shown as answers.
This question is locked. New answers and comments are not allowed.
Gary
Top achievements
Rank 1
Gary asked on 31 Aug 2015, 01:28 PM

I am doing what seems like what is probably a pretty common task with OpenAccedd/Data Access and that is supplying a WebAPI web service with data to fulfill it's requests. I am running into the typical issue of the entities getting serialized and the graphs getting ​serialized out as well.

The suggestions I have read have been to explicitly set the FetchStrategy on the context when the query is executed, and that this would limit the navigation properties that were expanded when serialized. That, in addition to creating a detached copy should resolve the issue. I must be doing something wrong however because I have had no luck doing these things. 

 

 

01.//
02.// WEB API GET METHOD
03.public class CatalogAPIController : ApiController
04.{
05.    [HttpGet]
06.    public HttpResponseMessage Get()
07.    {
08.        HttpResponseMessage ret;
09. 
10.        try
11.        {
12.            List<DeliverableType> data = CatalogAdminAppRepository.GetDeliverableTypeList();
13.            //
14.            // Package the data in a Custom Response container
15.            CustomHttpResponse<DeliverableType> response = CustomResponse<DeliverableType>.Create(data);
16.            //
17.            // Package the container into a HttpResponseMessage to be returned
18.            ret = Request.CreateResponse<CustomHttpResponse<DeliverableType>>(HttpStatusCode.OK, response);
19.        }
20.        catch (Exception ex)
21.        {
22.            CustomHttpResponse<Exception> response = CustomHttpResponse<Exception>.CreateForException(ex);
23.            ret = Request.CreateResponse<CustomHttpResponse<Exception>>(HttpStatusCode.InternalServerError, response);
24.        }
25. 
26.        return ret;
27.    }
28.}
29. 
30.//
31.// The Repository code which retrieves the Entity from the context.
32.public class CatalogAdminAppRepository : ICatalogAdminAppRepository
33.{
34.    public static DeliverableType GetDeliverableTypeByID(Int64 typeID)
35.    {
36.        DeliverableType ret = null;
37. 
38.        using (CatalogAdminDbRepository<DeliverableType> repo = new CatalogAdminDbRepository<DeliverableType>())
39.        {
40.            //
41.            // define a fetch strategy to get only the navigation properties we are
42.            // interested in, limiting the depth to only 1 layer. This should prevent
43.            // the serialization of any navigation properties associated with the
44.            // Deliverables and Type properties.
45.            FetchStrategy fetch = new FetchStrategy();
46.            fetch.LoadWith<DeliverableType>(e => e.Deliverables);
47.            fetch.LoadWith<Deliverable>(e => e.Type);
48.            fetch.MaxFetchDepth = 1;
49.            //
50.            // Associate the fetch strategy to the Context being used to
51.            // retrieve the entity collection
52.            repo.DbContext.FetchStrategy = fetch;
53.            ret = repo.GetEntityByID(typeID);
54.            //
55.            // also assign it to the CreateDetachedCopy method
56.            ret = repo.DbContext.CreateDetachedCopy<DeliverableType>(ret, fetch);
57.        }
58. 
59.        return ret;
60.    }
61.}

  

So I have done the following things to prevent the loading of navigation properties when they serialize ... 

  • Disposed of the Context
  • Defined an explicit FetchStrategy
  • Created a detached copy

After all of this everything is STILL being loaded. I must be missing something. Can you see what I am overlooking?

 

An aside question I have is ... If the context is where all the connection information is stored, how is it possible for these navigation properties to load once the Context has been disposed of?

1 Answer, 1 is accepted

Sort by
0
Gary
Top achievements
Rank 1
answered on 31 Aug 2015, 02:10 PM

I figured out the problem ... it was 1 part stupid (the posted method example is not the method that was being called) and 1 part DOH! (I was still returning the UNDETACHED resultset anf not the DETACHED copy that I made). If you could delete this post that would probably be for the best. Otherwise it may just sit here and confuse people. 

Ugghh .. Mondays 

Tags
Data Access Free Edition
Asked by
Gary
Top achievements
Rank 1
Answers by
Gary
Top achievements
Rank 1
Share this question
or