Что лучший способ состоит в том, чтобы возвратить общее количество объекта из репозитория getitems метод

У нас есть следующий метод репозитория

public IList<Foo> GetItems(int fooId, int pageIndex, int pageSize
, string sortField, string sortDir, out int totalItems)
{
// Some code
}

Мой вопрос: это в порядке для использования out таким образом. Мне несколько неудобно с out, но не может придумать лучший способ записать это как единственный вызов.

1
задан skaffman 4 May 2010 в 18:15
поделиться

3 ответа

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

Оказывается, гуру MVC Роб Конери некоторое время назад писал об использовании PagedList. Это элегантный шаблон, и, согласно блогу, ScottGu использовал его в демонстрациях. По сути, вместо использования IList и List вы используете IPagedList и PagedList . PagedList : список , IPagedList .

public interface IPagedList
{
    int TotalCount { get; set; }
    int PageIndex  { get; set; }
    int PageSize { get; set; }
    bool IsPreviousPage { get; }
    bool IsNextPage { get; }   
}

Там еще код, так что загляните в блог Роба.

http://blog.wekeroad.com/blog/aspnet-mvc-pagedlistt/

1
ответ дан 3 September 2019 в 00:49
поделиться

Что насчет этого?

public class ItemsList
{
    public IList<Foo> Items { get; set; }
    public int TotalCount { get; set; }
}

public ItemsList GetItems(int fooId, int pageIndex, int pageSize, string sortField, string sortDir)
{
    return new ItemsList { Items = ..., TotalCount = ... };
}

Вы также можете сохранить дополнительную информацию.

public class ItemsList
{
    public IList<Foo> Items { get; set; }
    public int TotalCount { get; set; }
    public string SortField { get; set; }
    public string SortDirection { get; set; }
    public int PageIndex { get; set; }
    public int PageSize { get; set; }
}

Или даже создать общий класс.

1
ответ дан 3 September 2019 в 00:49
поделиться

Не понимаю, почему вы хотите сделать это за один звонок. Если вам нужно оптимизировать круговой обход репозитория для отдельного вызова общего подсчета, я считаю, что вы преждевременно выполняете микрооптимизацию, если не измеряете, что этот конкретный вызов является вашей проблемой производительности. И если вы измерили это, и это так, я думаю, у вас большие проблемы с вашим репозиторием.

Лично я бы придерживался простого свойства Count того же объекта, который предоставляет GetItems выше.

Обновление: Чтобы ответить на ваш вопрос, есть ли причины не разрабатывать его как единый вызов:

Это делает ваш API более сложным и неоднозначным, чем он должен быть. GetItems () основное намерение (как заявлено выше) состоит в том, чтобы иметь дело с одной страницей элементов; добавление параметра out для общего количества элементов перегружает эту семантику.

Вот что нужно учесть - если меня интересует только общее количество элементов, мне придется вызывать GetItems или будет отдельный метод? Если существует отдельный метод, почему существует два способа доступа к одной и той же информации и возможно ли, что они могут возвращать разные результаты? А если отдельного результата нет, зачем мне получать полную страницу записей только для того, чтобы получить общее количество элементов в репозитории?

0
ответ дан 3 September 2019 в 00:49
поделиться
Другие вопросы по тегам:

Похожие вопросы: