Могу ли я иметь/использовать поле/свойство со списком‹Class‹T››, где T может быть чем угодно?

Это классическая ситуация. Раньше тоже много раз спрашивал. Я вижу два подхода.

-> Очевидным выбором было бы иметь необщий базовый класс/интерфейс, который может учитывать все ваши типы запросов, а затем использовать List<NonGenericRequest>.

-> Второй подход будет использовать ковариацию. Я вижу, вы столкнулись с некоторыми проблемами. Я попробую решить ее, одну за другой:

Ну, интерфейсы не могут иметь поля. Поэтому мне пришлось бы привести элемент списка к экземпляру Request<>, чтобы получить доступ к тому, что я хочу.

Не используйте поля. Даже не думай об этом. Переключитесь на свойства. Я должен повторить мысль. Интерфейсы — фактически все общедоступные API — имеют дело со свойствами.

Или я мог бы установить свойства в интерфейсе. Но затем он говорит мне, что я не могу использовать ключевое слово out

Проблема заключается в установщиках ваших свойств. Это нарушает безопасность типов. См. этот поток для более.

Это означает, что часть <TRequest,TResponse> будет бесполезна. Это означает, что я буду использовать только список, и ответ на мой вопрос Stackoverflow: нет, вы не можете использовать/выгодно хранить List<Class<T>> в C#.

К настоящему времени вы можете написать что-то вроде var requests = new List<IRequest<object, object>>(). Но это означает, что вы не получаете строго типизированные TRequest и TResponse. Решение состоит в том, чтобы избавиться от аргументов универсального типа TRequest и TResponse (т. е. вашего ограничения where T : class) и включить более удобное ограничение. Что-то полезное для вас.

Объединив их все, мы идем:

interface IMessage //I will call it IMessage for now
{
    //implement whatever that make deserializing possible
}

class FooRequest : IMessage
{

}

class BarResponse : IMessage
{

}

interface IRequest<out TRequest, out TResponse>
    where TRequest : IMessage 
    where TResponse : IMessage 
{
    TRequest RequestItem { get; }
    TResponse ResponseItem { get; }
    //whatever fits, but only getters for out parameter types
}

class Request<TRequest, TResponse> : IRequest<TRequest, TResponse>
    where TRequest : IMessage 
    where TResponse : IMessage 
{
    //you can extend interface properties with setters here
}

Итак, теперь вы можете написать:

var requests = new List<IRequest<IMessage, IMessage>>();
var a = new Request<FooRequest, BarResponse>();
requests.Add(a);
foreach (var request in requests)
{
    Deserialize(request);
}

void Deserialize<TRequest, TResponse>(IRequest<TRequest, TResponse> request)
    where TRequest : IMessage
    where TResponse : IMessage
{
    //have access to request.RequestItem, request.ResponseItem etc
}

Примечание. Для простоты я предположил, что TRequst и TResponse являются похожими типами, и, следовательно, оба они произошли от IMessage. Для них можно использовать отдельные интерфейсы типа IRequest и IResponse.

Вы можете воспользоваться разнообразием интерфейса, извлекая вариант IRequest интерфейса:

interface IRequest<out T, out T1>
{
}

и реализуйте его в своем классе запросов:

class Request<TRequest, TResponse> : IRequest<TRequest, TResponse>
    where TRequest : class
    where TResponse : class

Это позволит вам создать List<IRequest< object, object>>, который может хранить произвольные IRequest экземпляры:

var s = new List<IRequest< object, object>>();
s.Add(new Request<c1, c2>());

Вам все равно придется привести содержимое списка к более конкретному классу, если вы хотите какое-то поведение, специфичное для типа. Это может или не может повлиять на производительность в ситуациях с интенсивным трафиком.

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

abstract class BaseRequest
{
    public string RequestContent { get; protected set; }
    public string ResponseContent { get; set; }
}

class Request<TRequest, TResponse> : BaseRequest
    where TRequest : class
    where TResponse : class

а можно еще написать:

var s = new List<BaseRequest>();
s.Add(new Request<c1, c2>());

Я думаю, что общие подстановочные знаки могут помочь вам в этом: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2633766-wildcard-generic

Так как этого не произойдет по крайней мере в ближайшее время, я вижу три варианта:

• Вы можете голосовать, ждать и надеяться, что Microsoft примет подстановочные знаки в дженериках...
• Как прокомментировал Мрида, вы можете преобразовать свой код для использования интерфейсов, а затем использовать ковариантность С#.
• Если ковариация не является приемлемым решением, вы можете определить необщий базовый класс RequestBase только с неуниверсальной функциональностью и составить список RequestBase (изменить: я думаю, что это комментарий Хенка Холтермана). ). В качестве альтернативы, если вы не хотите изменять класс Request, вы можете определить неуниверсальную оболочку с неуниверсальной функциональностью.