IOC во время компиляции

Кто-нибудь начал проект для выполнения IOC во время компиляции (возможно, используя Roslyn или Linq MethodInfo emit)?

Мой опыт работы с контейнерами IOC до сих пор был замечательным, за исключением нескольких небольших проблем.

Многие контейнеры IOC запускаются медленно, так как большая часть логики разрешения происходит здесь
Часто трудно гарантировать, что разрешение возможно, так как компиляция больше не гарантирует, что конструктор может быть вызван
Часто контейнеры IOC добавляют небольшие накладные расходы к среде выполнения (некоторые даже не маленькие, часто те, которые запускаются быстро, работают медленно)

Мне кажется, что идеальным решением было бы добавить шаг компиляции в цепочку сборки, которая добавляет класс Factory вместо IOC.

Кто-нибудь делал это раньше? Если нет, то почему нет?

c# meta-programming inversion-of-control

— иСКУССТВ
источник

Ответы:

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

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

— Euphoric
источник

Да, я знаю, что это возможно. Но мне еще предстоит увидеть контейнер IoC, который это делает. Также я отметил, что в настоящее время наблюдается тенденция к регистрации в коде (свободные API). Учитывая это, я рассматриваю возможность написания упомянутого контейнера IoC.

— АрЦ

Кажется, я помню, что Хиро ( github.com/philiplaureano/Hiro ) мог делать свое дело во время компиляции.

— lzcd

«Но, делая это, вы устраняете одно огромное преимущество IoC: возможность изменять состав компонентов без необходимости перекомпиляции всего приложения». Мне кажется, что применять это ко всему приложению - это излишне; Вы превращаете каждую часть приложения в плагин. Кроме того, обе технологии должны сосуществовать - нет причин, по которым вы не можете подключить некоторые компоненты во время компиляции, а некоторые - во время выполнения.

— Доваль

Я не понимаю, как это огромное преимущество. В каком контексте вы полностью заменяете компоненты во время выполнения? Может быть, несколько вариантов использования конфигурации?

— andyczerwonka

Dagger для Java / Android делает это. Он жертвует некоторой магией времени исполнения (например, Guice), чтобы предложить практически полностью кодированный код времени компиляции, включая преобразование большинства ошибок времени выполнения в ошибки компиляции.

Было бы круто в .NET тоже.

— orip
источник