C# «Анонимный» тип списка, хранящийся в словаре

Question

Я прихожу к выводу, что это может быть невозможно, но я подумал, что попрошу здесь, прежде чем полностью отказаться. То, что я ищу что-то похожее на это:

Dictionary<string, List<T>> FilterLists { get; set; } 

Я хочу, чтобы иметь возможность хранить любое количество списков, которые могут быть необходимы, а затем быть в состоянии найти их с помощью строки Key «индекс».

Причина, по которой мне это нужно, из-за того, что это должно быть сохранено из-за определенных ограничений, и было бы невозможно напечатать Список как что-то конкретное, потому что он не может видеть тип объекта, который я хочу положил туда. Даже если бы я мог видеть тип объекта, это уменьшает его повторное использование в других проектах, где то, что кто-то может захотеть вставить туда, может быть построено по-разному, и я пытаюсь сделать это как можно многоразовое.

Я нашел это сообщение: Declaration of Anonymous types List, но это не совсем работает с тем, что я пытаюсь сделать.

Кроме того, это должно пройти в классе интерфейса, поэтому это просто определение.

Использование Пояснение: Это специально используется для разбивки на страницы в приложении MVC5. Возвращается список результатов, но я также хочу, чтобы в некоторых столбцах заголовка были выбраны фильтры выпадающего списка (например, вы увидите в Excel-фильтрацию столбцов).

Я стараюсь избегать использования ViewBag в максимально возможной степени по нескольким причинам. Мне не нравится использовать его. Мой код «Pagination» находится в проекте, известном как Common на уровне, чтобы сделать его доступным как для моего веб-проекта, так и для моего проекта сервиса (Business Logic layer). Модели и модели ViewModels, которые я использую, хранятся в Сервисе, поэтому я не могу иметь службу Common referencing, потому что Service уже ссылается на Common для настраиваемой конструкции IPagedList, используемой для определения списка объектов, которые будут разбиты на страницы. IPagedData содержит множество свойств для фильтрации, сортировки и разбиения на страницы набора результатов. Для облегчения этих операций над данными было создано расширение LINQ (.ToPageList). Есть несколько объектов, связанных с этим процессом, но я, по крайней мере, опубликую IPagedData (где я хочу, чтобы этот словарь прошел).

using System.Collections.Generic; 

namespace GameKeyExchange.Common.Pagination 
{ 
    public interface IPagedData 
    { 
     Dictionary<string, List<T>> FilterLists { get; set; } 

     /// <summary> 
     /// Stores pagination and sort information. 
     /// </summary> 
     PageSortCriteria Criteria { get; set; } 

     /// <summary> 
     /// Total number of subsets within the superset. 
     /// </summary> 
     int PageCount { get; } 

     /// <summary> 
     /// Total number of objects contained within the superset. 
     /// </summary> 
     int TotalItemCount { get; } 

     /// <summary> 
     /// Zero-based index of this subset within the superset. 
     /// </summary> 
     int PageIndex { get; } 

     /// <summary> 
     /// One-based index of this subset within the superset. 
     /// </summary> 
     int PageNumber { get; } 

     /// <summary> 
     /// Maximum size any individual subset. 
     /// </summary> 
     int PageSize { get; } 

     /// <summary> 
     /// Returns true if this is NOT the first subset within the superset. 
     /// </summary> 
     bool HasPreviousPage { get; } 

     /// <summary> 
     /// Returns true if this is NOT the last subset within the superset. 
     /// </summary> 
     bool HasNextPage { get; } 

     /// <summary> 
     /// Returns true if this is the first subset within the superset. 
     /// </summary> 
     bool IsFirstPage { get; } 

     /// <summary> 
     /// Returns true if this is the last subset within the superset. 
     /// </summary> 
     bool IsLastPage { get; } 
    } 
} 

Реализация кода будет идеально выглядеть в моей службе:

var list = data.ClaimedKeys.Where(m => m.UserId == UserId).Select(m => new ClaimedKeysViewModel() 
{ 
    KeyTypeId = m.GameKey.GameKeyGroup.KeyTypeId, 
    PlatformId = m.GameKey.GameKeyGroup.PlatformId, 

    Value = m.GameKey.Value, 
    KeyType = m.GameKey.GameKeyGroup.KeyType.Name, 
    Game = m.GameKey.GameKeyGroup.Game.Name, 
    Platform = m.GameKey.GameKeyGroup.Platform.Name, 
    Expiration = m.GameKey.GameKeyGroup.Expiration 
}) 

list.FilterLists.Add("KeyTypeFilter", list.Select(m => new List<SelectListModel>() 
{ 
    Value = m.KeyTypeId, 
    Text = m.KeyType 
}); 

list.FilterLists.Add("PlatformFilter", list.Select(m => new List<SelectListModel>() 
{ 
    Value = m.PlatformId, 
    Text = m.Platform 
}); 

list.OrderBy(string.Format("{0} {1}", sort, order)) 
    .ToPagedList<ClaimedKeysViewModel>(pageNumber, pageSize); 

Таким образом, я могу получить список данных постраничный в службе, строить свою нумерацию страниц, а также включать в себя любой количество списков фильтров, которые отправляются обратно контроллеру. Контроллер получает это: IPageList, который является списком данных, включая эти дополнительные свойства для сортировки и фильтрации. Причина, по которой они передаются вместе со списком данных, заключается в том, что при нажатии на заголовок или изменении страницы вы точно знаете, на какой странице вы находитесь, и на текущий статус вашей сортировки, когда он выбирает каждую страницу или курорты.

В противном случае, я должен сделать вторичный вызов базы данных для создания моих фильтров и отправки их в виде объектов ViewBag. Кроме того, поскольку начальный вид и метод обновления (который используется после начальной загрузки для использования или навигации по страницам), я должен иметь один и тот же код в обоих методах для создания списков. Если я могу получить его в методе службы, который генерирует список, его нужно только сделать там; тот же метод, который уже вызывается в обоих методах контроллера.

Надеюсь, это лучше пояснит прецедент.