Как написать код, расширяемый пользователем?

Как программист на Perl я могу оценивать строки как код. Если я хочу, могу ли я сделать то же самое на C # (со строками или каким-либо другим объектом, содержащим пользовательский ввод)?

Я хочу создать объект, методы которого могут быть предопределены в моем исходном коде или могут быть определены пользователем во время выполнения путем ввода строки, представляющей код C # для метода или SQL-запроса. Вызов метода всегда должен возвращать свое скалярное значение в виде строки, я считаю, что было бы желательно сделать доступными некоторые предопределенные «системные» переменные для использования в вызове метода и некоторый код «очистки» для проверки того, что строка действительно возвращается. .

Псевдо - Структура

 Object Statistic
      string  Name;
      functionref Method;

Архитектура, которую я имею в виду, будет собирать их в реальном времени и добавлять их по запросу пользователя в список статистики, которую пользователь хочет отобразить. Определенная статистика может быть сохранена в файл и загружена в основную программу во время инициализации. Таким образом, пользователю не нужно постоянно переопределять желаемую статистику. Правка / Обновление / Удаление статистики необходимы.

Если это удастся, мне (программисту) не придется добавлять новый код каждый раз, когда кто-то решает, что у него есть новая часть информации, которую он хочет отображать на своей статистической доске, для которой я еще не написал код.

Есть идеи о том, с чего начать чтение, чтобы добиться этого на C #?

Целью этой возможности является программа, отображающая статистику для работающей системы / базы данных. Значения для отслеживания не обязательно известны ни во время разработки, ни как определить значение, желаемое для извлечения. Я хочу разрешить пользователю определять любую статистику помимо любого предварительного кода для системы.


person Steve    schedule 17.03.2009    source источник


Ответы (2)


Прочтите этот предыдущий вопрос.

Однако также следует учитывать стабильность, масштабируемость и безопасность вашего решения. Если вы разрешите произвольное выполнение, ваше приложение будет неинтересным в эксплуатации и поддержке. Установите очень четко разграниченную песочницу для кода, предоставляемого извне.

Кроме того, не ожидайте, что обычные пользователи (кем бы они ни были) способны кодировать.

Возможно, вы захотите предложить ограниченную, но более управляемую расширяемость, например, Вместо этого внедрение зависимости.

person Pontus Gagge    schedule 17.03.2009

Я повторю то, что сказал Понтус, особенно в отношении стабильности, затрат на поддержку и ожиданий, что пользователи будут писать код. Я также добавлю производительность в список, поскольку эти пользователи, вероятно, не знают о влиянии их кода на производительность. По этим и другим причинам обращенные к пользователю eval-подобные конструкции не считаются разумными в C #, и, вероятно, не должны быть и в Perl.

Вместо этого посмотрите на пространство имен System.AddIn в .Net, чтобы обеспечить функциональность плагина для вашего приложения.

person Joel Coehoorn    schedule 17.03.2009