Выборка / возврат данных со связанными коллекциями данных в сервисной архитектуре - PullRequest
Новая
       1

Выборка / возврат данных со связанными коллекциями данных в сервисной архитектуре

1 голос
/ 07 декабря 2011

Вот так выглядит мой .EDMX 

Entity
    int Prop1;
    String Prop2;
    EntityCollection<ChildEntity1> Children;
    EntityCollection<ChildEntity2> OtherRelatedData;

Естественно, на моем сервисном уровне это работает хорошо, я могу выполнять бизнес-логику, просто используя свойства .Children и .OtherRelatedData, и, поскольку они все еще IQueryable, я могу без проблем проецировать их на контент моего сердца. , У меня вопрос такой; как мой сервис должен выставить эти данные? Позвольте мне решить проблему.

Количество ChildEntity1 записей будет расти вечно, поэтому, когда клиенты службы запрашивают Entity, я не хочу просто .ToList(), так как могут быть тысячи связанных строк (и, как правило, только большинство последние 10-100 будут полезны).

Я пытаюсь выбрать между этими двумя подходами:

Вариант один 

// Service Code
public EntityDTO ReadEntity(int id)
{
    // return Entity based on id with both child properties null
}
public IEnumerable<ChildEntity1DTO> ReadChildEntity1s(int parentID, int take, int skip)
{
    // return ChildEntity1DTOs starting at skip and returning only at most take
}
public IEnumerable<ChildEntity2DTO> ReadChildEntity2s(int parentID, int take, int skip)
{
    // return ChildEntity2DTOs starting at skip and returning only at most take
}

// consumer code
var ent = svc.ReadEntity(3);
var Entity = new 
{
    Prop1 = ent.Prop1,
    Prop2 = ent.Prop2
    Children = svc.ReadChildEntity1s(3, 10, 0),
    OtherRelatedData = svc.ReadChildEntity2s(3, 10, 0)
};

Вариант второй 

// Service Code
public EntityDTO ReadEntity(int id, int takeChild1, int skipChild1, int takeChild2, int skipChild2)
{
    // do projection of data here and return one DTO fully pre-populated
}

// client
var e = svc.ReadEntity(3, 10, 0, 10, 0);

Я склоняюсь к Варианту 1, просто потому, что это значительно упростит нумерацию страниц на клиенте, просто попросив клиента запросить дополнительные связанные записи. Для того, чтобы поддержать ту же нумерацию страниц для Варианта Два, я должен был бы добавить все тот же код из Варианта Один также. При первом варианте я получаю дополнительную выгоду от пропуска всех связанных данных, если потребитель не заинтересован в них по умолчанию, вместо того, чтобы указывать пропустить ноль, для каждого связанного набора берется ноль.

Есть ли лучший подход к обработке ситуаций такого типа с DTO в сервисной архитектуре?

1 Ответ

0 голосов
/ 07 декабря 2011

Я склоняюсь к Варианту 1, просто потому, что это сильно увеличит нумерацию страниц на клиенте

Я надеюсь, что вы стажер.

Не знаете ли вы, что вы можете предоставить IQueryable как IQUERYABLE клиенту, тогда клиент может использовать обычные операторы Skio / Take LINQ?

Не знаете ли вы, что WCF может отобразить IQueryable на строку запроса OData? Что позволяет пользователю с помощью параметров в URL определять порядок, условия, фильтрацию, подкачку?

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

http://www.c -sharpcorner.com / uploadfile / dhananjaycoder / введение к ФОС-данных-сервис-и-OData /

имеет хорошее начало.

...