Сообщение Вывод общего интерфейса - возможно ли? от 13.06.2018 19:51
Изменено 13.06.2018 20:39 LWhisper
Вывод общего интерфейса - возможно ли?
Возможно ли реализовать подобное в C#/F# сейчас или в ближайшем будущем без использования dynamic?
В случае Extension-методов возникает проблема написания кода для всех возможных комбинаций интерфейсов.
Вариант с рантайм-генерацией типов подходит, но возникает вопрос — каким должно быть возвращаемое значение? Как описать T + IInterface?
Почему не подходит контейнер — отсутствие проверок на этапе компиляции. Да, Resolve<IService> будет бросать исключения, если зависимости не были проинициализированы, но узнаем мы об этом только в рантайме.
Вроде, можно не выпендриваться и передавать именовпнные таплы. Но если об этом подумать, то и таплы не нужны — в одном месте зависимость разрешил, и тащишь ее через все слои вниз. Вот только там, где сейчас один контейнер появятся десятки аттрибутов или опять же скомбинированные хелпер-контейнеры. И это без масштабных нарушений ответственности, а они есть и будут есть.
var service = new StupidService()
.Smart()
.Useful();
ISmartService s1 = service;
IUsefulService s2 = service;
В случае Extension-методов возникает проблема написания кода для всех возможных комбинаций интерфейсов.
Вариант с рантайм-генерацией типов подходит, но возникает вопрос — каким должно быть возвращаемое значение? Как описать T + IInterface?
Почему не подходит контейнер — отсутствие проверок на этапе компиляции. Да, Resolve<IService> будет бросать исключения, если зависимости не были проинициализированы, но узнаем мы об этом только в рантайме.
Вроде, можно не выпендриваться и передавать именовпнные таплы. Но если об этом подумать, то и таплы не нужны — в одном месте зависимость разрешил, и тащишь ее через все слои вниз. Вот только там, где сейчас один контейнер появятся десятки аттрибутов или опять же скомбинированные хелпер-контейнеры. И это без масштабных нарушений ответственности, а они есть и будут есть.
Вывод общего интерфейса - возможно ли?
Возможно ли реализовать подобное в C#/F# сейчас или в ближайшем будущем без использования dynamic?
В случае Extension-методов возникает проблема написания кода для всех возможных комбинаций интерфейсов.
Вариант с рантайм-генерацией типов подходит, но возникает вопрос — каким должно быть возвращаемое значение? Как описать T + IInterface?
Почему не подходит контейнер — отсутствие проверок на этапе компиляции. Да, Resolve<IService> будет бросать исключения, если зависимости не были проинициализированы, но узнаем мы об этом только в рантайме.
Вроде, можно не выпендриваться и передавать именовпнные таплы. Но если об этом подумать, то и таплы не нужны — в одном месте зависимость разрешил, и тащишь ее через все слои вниз. Вот только там, где сейчас один контейнер появятся десятки аттрибутов или опять же скомбинированные хелпер-контейнеры. И это без масштабных нарушений ответственности, а они есть и будут есть.
Подумав немногл, понял, что просто неверно думаю о реализации IOC-контейнеров. У него должна быть возможность разрезолвить любой сервис без необходимости вручную задавать зависимости. В таком случае и проблемы не будет как таковой. Просто провайдер микросервисов... Это нужно обдумать.
var service = new StupidService()
.Smart()
.Useful();
ISmartService s1 = service;
IUsefulService s2 = service;
В случае Extension-методов возникает проблема написания кода для всех возможных комбинаций интерфейсов.
Вариант с рантайм-генерацией типов подходит, но возникает вопрос — каким должно быть возвращаемое значение? Как описать T + IInterface?
Почему не подходит контейнер — отсутствие проверок на этапе компиляции. Да, Resolve<IService> будет бросать исключения, если зависимости не были проинициализированы, но узнаем мы об этом только в рантайме.
Вроде, можно не выпендриваться и передавать именовпнные таплы. Но если об этом подумать, то и таплы не нужны — в одном месте зависимость разрешил, и тащишь ее через все слои вниз. Вот только там, где сейчас один контейнер появятся десятки аттрибутов или опять же скомбинированные хелпер-контейнеры. И это без масштабных нарушений ответственности, а они есть и будут есть.
Подумав немногл, понял, что просто неверно думаю о реализации IOC-контейнеров. У него должна быть возможность разрезолвить любой сервис без необходимости вручную задавать зависимости. В таком случае и проблемы не будет как таковой. Просто провайдер микросервисов... Это нужно обдумать.