RIA Services и множественные / динамические стратегии включения - PullRequest
2 голосов
/ 27 апреля 2010

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

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

public class LineItem { }
public class Fee { }

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

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

Ответы [ 3 ]

0 голосов
/ 09 января 2011

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

0 голосов
/ 21 ноября 2012

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

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

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

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

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

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

0 голосов
/ 24 июня 2010

Вы бы сделали это так:

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