Include property but exclude one of that property's properties

后端 未结 1 1674
终归单人心
终归单人心 2020-12-03 11:13

Let\'s say I have a method like this in one of my controllers:

[Route(\"api/Products\")]
public IQueryable GetProducts() {
    return db.Produ         


        
相关标签:
1条回答
  • 2020-12-03 11:50

    As said in the comments, the first step is to disable lazy loading. You can either do that by removing the virtual modifier from the collection properties, which is permanent, or by disabling it per context instance, which is temporary:

    context.Configuration.ProxyCreationEnabled = false;
    

    (disabling proxy creation also disables lazy loading, but keeps the generated objects more light-weight).

    In disconnected scenarios, like Web AIP2 (as you originally tagged the question), people often prefer to disable lazy loading by default, because of this serializer-lazy-loading cascade.

    However, you can't stop Entity Framework from executing relationship fixup. Loading a Productattaches it to the context. Include()-ing its categories attaches those to the context and EF populates their Products collections with the attached product, whether you like it or not.

    You can somewhat reduce this effect by fetching the products with AsNoTracking (which prevents entities to get attached, i.e. change-tracked):

    return db.Products.AsNoTracking()
             .Include(p => p.Category);
    

    Now categories will only have their Products filled with the Product of which they are the category.

    By the way, in disconnected scenarios, also using AsNoTracking is preferred. The entities won't ever be saved by the same context instance anyway and it increases performance.

    Solutions

    • Return DTOs, not entity types

    By using DTO objects you take full control over the object graph that will be serialized. Lazy loading won't surprise you. But yeah, the amount of required DTO classes can be overwhelming.

    • Return anonymous types.

    This will raise some eyebrows because we should never return anonymous types from methods, right? Well, they leave an action method as a Json string, just as named types, and the javascript client doesn't know the distinction. You might say that it only brings the weakly typed javascript environment one step closer. The only thing is that a named DTO type serves as a data contract (of sorts) and anonymous types can be changed (too) easily and break client-side code. But we always unit-test everything, do we? Hmm, it's a viable option in smaller development teams.

    • Tweak the serializer.

    You can tell the Json.Net serializer to ignore reference loops. Using JsonConvert directly, it looks like so:

    var products = db.Products.AsNoTracking().Include(p => p.Category);
    var setting = new JsonSerializerSettings
    {
        Formatting = Newtonsoft.Json.Formatting.Indented, // Just for humans
        ReferenceLoopHandling = ReferenceLoopHandling.Ignore
    };
    var json = JsonConvert.SerializeObject(products, setting);
    

    In combination with AsNoTracking() this will serialize the categories with empty Products arrays ("Products": []), because Product - Category - Product is a reference loop.

    In Web API there are several ways to configure the built-in Json.Net serializer, you may want to do this per action method.

    Personally, I prefer using DTOs. I like to be in control (also over the properties that cross the wire) and I don't particularly like to rely on a serializer to solve for me what I neglected to do.

    0 讨论(0)
提交回复
热议问题