Как заставить службы RIA включать дочернюю сущность в один метод запроса, но не в другой

#nhibernate #wcf-ria-services

#nhibernate #wcf-ria-services

Вопрос:

Вот сценарий:

У меня есть связь между «Группами» и «Пользователями», представленная объектом «UserGroupAssignment».

 public class UserGroupAssignment
{
  [Key]
  public virtual long Id { get; set; }

  [Association("UserAssignmentToUser", "UserId", "Id", IsForeignKey = true)]
  public virtual User { get; set; }  

  [Association("UserAssignmentToGroup", "GroupId", "Id", IsForeignKey = true)]
  public virtual Group { get; set; }    

  public virtual bool IsPrimary { get; set; }    

  public virtual DateTime? ValidFrom { get; set; }    

  public virtual DateTime? ValidTo { get; set; }    
}
  

У меня есть два метода бизнес-логики, GetUserAssignmentsForGroups и GetGroupAssignmentsForUsers, которым я возвращаю назначения с заполненными свойствами User и Group соответственно. т.е. GetUserAssignmentsForGroup принимает groupId и возвращает назначения для этой группы с заполненным свойством User.

Что я хочу, так это предоставить эти два метода в качестве методов запроса домена следующим образом:

 [Query]
public IQueryable<UserGroupAssignment> GetAssignmentsForGroupWithUsers(long groupId)
{
  return this.businessLogic.GetUserAssignmentsForGroups(groupId);
}

[Query]
public IQueryable<UserGroupAssignment> GetAssignmentsForUserWithGroups(long userId)
{
  return this.businessLogic.GetGroupAssignmentsForUsers(userId)
}
  

Моя проблема в том, что, хотя методы бизнес-логики возвращают правильно заполненные назначения через NHibernate, службы RIA НЕ передают дочерние сущности (пользователя или группу) по проводам.

Я не хочу использовать атрибуты [Include] в свойствах User или Group класса UserAssignment, поскольку я хочу минимизировать полезную нагрузку по проводам — я не хочу отправлять группу, когда меня интересует только пользователь каждого UserAssignment, например.

Итак, мой вопрос заключается в следующем:

Как мне указать службам RIA явно включать пользовательские дочерние сущности в один метод запроса домена и группировать дочерние сущности в другом?

Помните, я использую NHibernate в серверной части и пользовательские методы запроса в службах RIA, поэтому не могу использовать включение в стиле EF в клиентском запросе.

Спасибо

Джоэл

Комментарии:

1. Не уверен, как ответить на ваш вопрос, но вы могли бы рассмотреть возможность добавления тега [nhibernate], чтобы привлечь людей из этой области к помощи. тоже.

Ответ №1:

вы должны применить [Include] атрибут в классе метаданных. затем создайте один метод доменной службы для выборки данных, без включенных свойств, и отдельный метод для выборки данных с включенными свойствами.

Вы могли бы найти этот поток полезным для понимания того, как [Include] работает атрибут.

Ответ №2:

Старый вопрос, но все еще интересный. Вы нашли решение?

Насколько я знаю архитектуру WCF RIA, это не так просто. Простым и грязным способом могло бы быть переопределение метода запроса, принудительное перечисление возвращаемого IQueryable (я предполагаю, что вы используете LINQ для NHibernate, и в этом случае удачи), затем проверьте HttpContext (вы используете WCF RiaServices, поэтому у вас ДОЛЖНА быть включена совместимость aspNetCompatibility) и установите в null ссылку, которую вы не хотите отправлять по проводам (пользователю или группе). В любом случае этот способ ЗАСТАВИТ вас использовать [IncludeAttribute]. Однако я не вижу никакого разумного маршрута, который бы избегал ее использования, и этот способ позволит вам отправлять сущность по проводам именно тогда, когда вам нужно.

ИМО, я полагаю, что для того, чтобы полностью избежать использования [Include], вы должны развернуть свой собственный сериализатор на стороне сервера и десериализатор на стороне клиента или изменить объект UserGroupAssignment так, чтобы свойство user стало строкой, содержащей сериализованного пользователя (или группу), которого вы решаете оценивать или нет в соответствии с вашим методом.

Пожалуйста, дайте нам знать, если вы уже нашли решение, вопрос интересный.