RIA Services and multiple/dynamic "Include" strategies

As an example, assume the following simple model:

public class Order
{
    public List<LineItem> LineItems { get; set; }
    public List<Fee> Fees { get; set; }
}

public class LineItem { }
public class Fee { }

With RIA Services, if I want to retrieve an 开发者_如何学COrder and include all of it's line items in the same network call, I can statically place an [Include] attribute on the above LineItems collection. This works great for a single scenario, but what happens when I need multiple "include strategies"?

For instance, one situation might call for including the Fees collection and NOT the LineItems collection. Is there any way with RIA Services to control what's included at runtime without redefining your model and/or creating dtos with the attributes statically placed for each use-case?

[Include] attributes work only if the property is included by Entity Framework (or whatever you use). So although you cannot set [Include] based on current scenario, you can control what entities get included by setting .Include on EF queries. So instead of one function called GetProducts on your DomainService, you will probably have more (GetProductsWithComments, etc.) that will differ by includes set on the EF query (see Jonx's answer).

This is best done with views. If you can't do views you can create your own POCO entities/classes.

Since POCO classes do not exist in your domain model you need to do a couple of things to make them work with ria services.

1. Since ria is just a form of WCF with entity serialization, the POCO classes need to be decorated with the [DataContract] attribute.
2. Any member of the POCO class needs to be decorated with [DataMember]
3. At least one property of the POCO class needs to have [Key] attribute (System.ObjectModel.DataAnnotations) and must be unique to satisfy the Key attribute's validation.

Finally to be able to use those poco classes in your service, at least one service method has to return IEnumerable or IQueriable of that poco class.

Knowing this, you can create custom objects to represent the hierarchy of stuff that you need for the UI. The downside is that doing CRUD using these objects is a bit difficult. Those objects are more commonly used for display.

Further more I would advise you to mark your ria service as partial, and any custom service code that you write, to add it in another partial class that implements the service.... (Will save you a world of hurt when you are updating your domain model and regenerating the wcf ria service...)

You would do this like that:

var product = _productRepository.GetProductSet()
.Include("Tags")
.Include("Attachments")
.Include("Comments")
.Include("Comments.User")
.Include("Comments.User.UserDetails")
.FirstOrDefault(p => p.ProductId == productId);