RIA Services и несколько/динамический «Include» стратегии

Question

В качестве примера рассмотрим следующую простую модель:

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

public class LineItem { } 
public class Fee { } 

С RIA Services, если я хочу, чтобы получить заказ и включают в себя все его позиций в тот же сетевой вызов, я могу статически разместить атрибут [Include] в приведенной выше коллекции LineItems. Это отлично работает для одного сценария, но что происходит, когда мне нужно несколько «включенных стратегий»?

Например, одна из ситуаций может потребовать включения коллекции платежей и НЕ коллекции LineItems. Есть ли способ с RIA Services контролировать, что включено во время выполнения, без переопределения вашей модели и/или создания dtos с атрибутами, статически размещенными для каждого случая использования?

Answer 1

Это можно сделать так:

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

Answer 2

[Включить] атрибуты работают только если свойство включен Entity Framework (или что вы используете). Поэтому, хотя вы не можете установить [Include] на основе текущего сценария, вы можете контролировать, какие объекты включаются, установив .Include on EF query. Таким образом, вместо одной функции, называемой GetProducts на вашем DomainService, у вас, вероятно, будет больше (GetProductsWithComments и т. Д.), Которые будут отличаться, включая набор в запросе EF (см. Ответ Jonx).

Answer 3

Это лучше всего сделать с видами. Если вы не можете делать представления, вы можете создать свои собственные объекты/классы POCO.

Поскольку классы POCO не существуют в вашей модели домена, вам нужно сделать несколько вещей, чтобы заставить их работать с услугами ria.

1. Поскольку ria - это просто форма WCF с сериализацией сущности, классы POCO должны быть украшены атрибутом [DataContract].
2. Любой член класса POCO должен быть украшен [DataMember]
3. По крайней мере, одно свойство класса POCO должен иметь [ключ] атрибутов (System.ObjectModel.DataAnnotations) и должен быть уникальным, чтобы удовлетворить ключ проверка атрибута.

Наконец, чтобы иметь возможность использовать эти классы poco в своей службе, по крайней мере один метод службы должен возвращать IEnumerable или IQueriable этого класса poco.

Зная это, вы можете создавать собственные объекты для представления иерархии материалов, необходимых для пользовательского интерфейса. Недостатком является то, что выполнение CRUD с использованием этих объектов немного сложно. Эти объекты чаще используются для отображения.

Более подробно я бы посоветовал вам пометить ваш сервис ria как частичный и любой код служебного кода, который вы пишете, чтобы добавить его в другой частичный класс, который реализует сервис ... (спасет вас мир от ранения когда вы обновляете свою модель домена и восстанавливаете службу wcf ria ...)