Я с Вами полностью согласен. Для ситуации конфигурации сложного окружения такие средства незаменимы ( ну или заменимы большой кровью). Сами чем-то подобным пользуемся, хотя и далеко не на полную мощность
А вот тут мы приходим к вопросу подходов. Да, когда есть пару скриптов которые все настраивают/конфигурируют — это хорошо и удобно. Но это удобно для сложных настроек, которые реально нуждаются во внутренней логике, а не просто описывают a=8;b=2; Но это все равно остаётся делом эстетического вкуса и практического удобства, которые по большей части зависят от самого разработчика ( субъективного его понимания мира) и решаемых задач ( объективной реальности)
Я с Вами согласен касательно зависимостей. Хочу сказать, что это можно решать, если не забиваться на реализацию и архитектуру из коробки, но это снова же другая тема. А касательно кофига, то Вам же в любом случае нужно где-то сохранить что, куда и как грузить. И будь это конфиг, или база данных, или любой другой источник данных, это абсолютно не принципиально. Это же по сути просты данные, которые хотя и используются для настройки сервера, но все равно остаются данными, а не кодом, скриптом и тп
В asp.net путь по которому будет доступен метод контроллера, обычно, или выводиться из имён класса и метода, или прописываются атрибутом на них. Иногда это конфигурируют в стартапа. Но вот именно поменять адрес в процессе работы… Я таких методов не знаю, хотя я и не эксперт в asp.net (наверное поэтому и не знаю, но что на что менять в любом случае должно быть где-то прописано). Основная моя идея была в том, что мы дописываем в конфиг ( хотя у меня в проекте оно все совсем по другому храниться) связь адрес-функция в дол, и сервер подтягивает эту длл. Становится легче добавлять новую функциональность. Да и заменить имеющуюся иногда нужно. И даже не обязательно она будет с тем же набором аргументов (api тоже меняются), дальше там уже можно разные дергать в зависимости от того, какая версия api вызывается, но это уже другая история. Плюс, почему это было удобно нам в проекте, так это из-за того, что длл в шарпе не так просто выгрузить и на ее место выгрузить ее новую версию. Раньше это делалось только через appDomain, в core их поддерживать перестали и теперь это через assemblyLoadContext, но и там все не так просто. Поэтому иногда для быстрого и эффективного решения проблемы легче выгрузить новую длл и поставить новый обработчик на роут. А потом можно все перезапустить и сделать по людски. У нас это росло в рамках более глобальной инфраструктуры которая давала больше интересных возможностей, но это уже не для комментария
Идея хорошая. Я в python не разбираюсь от слова совсем, поэтому скажу как это выглядит для меня с моими C# и C++. Во-первых, когда вы храните конфигурации типа "по какому адресу что запустить", то это поведение можно легко менять для уже работающей программы. Не нужно ничего перезапускать, перекомпилировать, и тд, а это весьма неплохое техническое преимущество. Во-вторых, это даёт возможность легко расширять работающее приложение. Пишите функционал, загоняете в dll, пишите в конфиг, а Ваш сервер динамически грузит dll и получает новую функциональность ( не знаю, как это в Python, но думаю похожий механизм есть). А если у Вас функции написаны так, что им все равно в каком контексте они исполняются ( депенденси инжекшн и тп), то их становится намного легче автоматизировано тестировать, так как сервер теперь выступает по сути маршрутизатором к независимым функциям, и в тесте самой функции он не нужен. Я сам где-то похожую штуку сделал для своего проекта (правда похожа только идея, реализации весьма разные). Но хочу посоветовать, не очень увлекаться конфигом. Он хорош для описания простого связывания "пришел такой запрос-дернули такую функцию", но как только появится желание описать там поведение посложнее (ветвления и тп), то стоит ооочень подумать. Все же для описания сложного поведения язык программирования подойдёт лучше))
Удачи в дальнейшем развитии)
Я с Вами полностью согласен. Для ситуации конфигурации сложного окружения такие средства незаменимы ( ну или заменимы большой кровью). Сами чем-то подобным пользуемся, хотя и далеко не на полную мощность
А вот тут мы приходим к вопросу подходов. Да, когда есть пару скриптов которые все настраивают/конфигурируют — это хорошо и удобно. Но это удобно для сложных настроек, которые реально нуждаются во внутренней логике, а не просто описывают a=8;b=2; Но это все равно остаётся делом эстетического вкуса и практического удобства, которые по большей части зависят от самого разработчика ( субъективного его понимания мира) и решаемых задач ( объективной реальности)
Я с Вами согласен касательно зависимостей. Хочу сказать, что это можно решать, если не забиваться на реализацию и архитектуру из коробки, но это снова же другая тема. А касательно кофига, то Вам же в любом случае нужно где-то сохранить что, куда и как грузить. И будь это конфиг, или база данных, или любой другой источник данных, это абсолютно не принципиально. Это же по сути просты данные, которые хотя и используются для настройки сервера, но все равно остаются данными, а не кодом, скриптом и тп
Надеюсь в этот раз понятнее выразился, чем в предыдущем комментарии
В asp.net путь по которому будет доступен метод контроллера, обычно, или выводиться из имён класса и метода, или прописываются атрибутом на них. Иногда это конфигурируют в стартапа. Но вот именно поменять адрес в процессе работы… Я таких методов не знаю, хотя я и не эксперт в asp.net (наверное поэтому и не знаю, но что на что менять в любом случае должно быть где-то прописано). Основная моя идея была в том, что мы дописываем в конфиг ( хотя у меня в проекте оно все совсем по другому храниться) связь адрес-функция в дол, и сервер подтягивает эту длл. Становится легче добавлять новую функциональность. Да и заменить имеющуюся иногда нужно. И даже не обязательно она будет с тем же набором аргументов (api тоже меняются), дальше там уже можно разные дергать в зависимости от того, какая версия api вызывается, но это уже другая история. Плюс, почему это было удобно нам в проекте, так это из-за того, что длл в шарпе не так просто выгрузить и на ее место выгрузить ее новую версию. Раньше это делалось только через appDomain, в core их поддерживать перестали и теперь это через assemblyLoadContext, но и там все не так просто. Поэтому иногда для быстрого и эффективного решения проблемы легче выгрузить новую длл и поставить новый обработчик на роут. А потом можно все перезапустить и сделать по людски. У нас это росло в рамках более глобальной инфраструктуры которая давала больше интересных возможностей, но это уже не для комментария
Идея хорошая. Я в python не разбираюсь от слова совсем, поэтому скажу как это выглядит для меня с моими C# и C++. Во-первых, когда вы храните конфигурации типа "по какому адресу что запустить", то это поведение можно легко менять для уже работающей программы. Не нужно ничего перезапускать, перекомпилировать, и тд, а это весьма неплохое техническое преимущество. Во-вторых, это даёт возможность легко расширять работающее приложение. Пишите функционал, загоняете в dll, пишите в конфиг, а Ваш сервер динамически грузит dll и получает новую функциональность ( не знаю, как это в Python, но думаю похожий механизм есть). А если у Вас функции написаны так, что им все равно в каком контексте они исполняются ( депенденси инжекшн и тп), то их становится намного легче автоматизировано тестировать, так как сервер теперь выступает по сути маршрутизатором к независимым функциям, и в тесте самой функции он не нужен. Я сам где-то похожую штуку сделал для своего проекта (правда похожа только идея, реализации весьма разные). Но хочу посоветовать, не очень увлекаться конфигом. Он хорош для описания простого связывания "пришел такой запрос-дернули такую функцию", но как только появится желание описать там поведение посложнее (ветвления и тп), то стоит ооочень подумать. Все же для описания сложного поведения язык программирования подойдёт лучше))
Удачи в дальнейшем развитии)