МОК під час компіляції

Хтось розпочав проект, щоб зробити IOC під час компіляції (можливо, використовуючи Roslyn або Linq MethodInfo emit)?

Мій досвід роботи з контейнерами МОК до цього часу був чудовим і вирішував кілька невеликих питань

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

Мені здається, що ідеальним рішенням було б додати крок компіляції до ланцюга збирання, який додає клас Factory замість IOC.

Хтось робив це раніше? Якщо ні, то чому б і ні?

c# meta-programming inversion-of-control

— АРТ
джерело

Відповіді:

Зробити це не повинно бути такою проблемою. Просто запустіть ту саму логіку IoC і замість того, щоб інстанціювати класи, ви випромінюєте код, який робить інстанцію.

Але, виконуючи це, ви видаляєте одну величезну перевагу IoC: Можливість змінити склад компонентів без необхідності перекомпілювати всю програму. Просто замінивши конфігурацію, ви можете застосувати додатки для використання різних служб або джерел даних. І хоча я ще не бачив програми, яка б повністю використала цю можливість, вона все ще є важливою частиною успіху IoC.

— Ейфорія
джерело

Так, я знаю, що це можливо. Але я ще не бачив контейнер IoC, який це робить. Також я зазначив, що, схоже, поточна тенденція стосується реєстрації в коді (вільні API). Враховуючи це, я розглядаю можливість написання зазначеного контейнера IoC.

— ArTs

Я, мабуть, пам’ятаю, що Hiro ( github.com/philiplaureano/Hiro ) міг би робити свої речі під час компіляції.

— lzcd

"Але, роблячи це, ви видаляєте одну величезну перевагу IoC: Можливість змінити склад компонентів без необхідності перекомпілювати всю програму." Мені здається, що застосувати це до всієї програми надмірно; ви перетворюєте кожну частину програми в плагін. Крім того, обидві методи повинні мати можливість співіснувати - немає причин, коли ви не можете з'єднати деякі компоненти під час компіляції, а деякі - під час виконання.

— Doval

Я не бачу, як це величезна перевага. У якому контексті ви повністю замінюєте компоненти під час виконання? Можливо, кілька випадків використання конфігурації?

— andyczerwonka

Кинджал для Java / Android це робить. Він жертвує деякою магією виконання (на зразок Guice's), щоб запропонувати практично повністю компіляцію часу компіляції, включаючи перетворення більшості помилок виконання в помилки компіляції.

Буде круто і в .NET.

— оріп
джерело