Конфиги и данные в виде исполняемого кода
Поломать можно больше, чем через обычные конфиги.
Пока видится затруднённость (невозможность) горячей подгрузки.а в чем проблема?
Зависит от языка, если он позволяет это сделать безболезненно, то проблемы нет.
Зависит от языка, если он позволяет это сделать безболезненно, то проблемы нет.в java в чем проблема?
в питоне такое видел Отличная тема
И если в случае конфигов с этим можно жить, то в случае данных уже нет, ибо их существенно больше (оверхеды на сборку и правятся другими людьми (не программистами).
на SHell так и делают всегда
Невыполнены оба пункта из допущений.неужто в java нельзя динамически компилировать код, в .NET это делается через Emit
И если в случае конфигов с этим можно жить, то в случае данных уже нет, ибо их существенно больше (оверхеды на сборку и правятся другими людьми (не программистами).
погугли на тему java dynamically compilation code
вот тут меняют текстовый файл с кодом, и приложение его подхватывает, по-моему, как раз то, что тебе хочется
http://www.javaworld.com/javaworld/jw-06-2006/jw-0612-dynami...
Можно динамически, да. Но вот полная сборка проекта существенно дольше и пропорциональна кол-ву данных (а их много, обычно сильно больше, чем кода).
И читаемость у java-кода не ахти для непосвещённого. А надо еще и писать, не только читать.
Какие минусы есть такого подхода?Как и у любой дырки, позволяющей выполнить левый код.
Встречал подобное в ruby-приложении, показалось интересным.что именно видели? дайте ссылочку\ключевые слова, пожалуйста, потому что не очень ясно о чем речь.
если речь о встраивании скриптового языка в приложение, то таким образом не каждый ресурс\данные можно запихать, да и проблемы с предоставлением песочницы могут быть, и не ясно какие возможности\ограничения накладывает такой метод определения входных данных, т.к. язык общего назначения
Рассадник трудноуловимых багов, руки надо отрывать за такое по-хорошему:)
Это следствие того, что почти забесплатно переносится часть логики исполнения в данные (что есть осознанный выбор разработчика
а защититься от исполнения левого кода достаточно легко единожды написанными проверками.
а вот конфиг - его же редактировать надо?
Я к этому отношусь сугубо положительно, например. А вот к исполняемым конфигам — совершенно не так положительно.
В скриптовых языках типа php такое используется повсеместно. А для bash'а так и вообще существует устоявшееся название "dot file" от команды ". my_config.sh".
Минусы/плюсы очевидны:
- (-) В "конфиге" будет частично код — нужно тщательнее тестировать код в связке с "конфигом" при деплое
- (-) Нужно следить за тем, чтобы девелоперы не начали в "конфиг" засовывать весь код
- (-) Не-девелоперам будет сложнее править конфиг
- (+) Не нужны парсеры и маппинг между конфигом в объекты
ещё в плюсы можно записать то, что распространять приложение можно одним исполняемым файлом (и конфиг, и ресурсы - всё в одном) - порой очень удобно.
Оставить комментарий
danilov
Пусть есть приложение, у него имеются конфигурационные данные и данные приложения (все, кроме бинарных).Допустим
1. Язык позволяет держать данные одновременно и human-readable и исполняемыми. То есть они преставляют собой код, написанный на языке.
2. Нет больших оверхедов на сборку проекта в таком виде.
Какие минусы есть такого подхода? Интерес исключительно праздный, Java для этого слишком непригодна. Встречал подобное в ruby-приложении, показалось интересным. Пока видится затруднённость (невозможность) горячей подгрузки. Но эта проблема есть и при разделённом подходе.