Архитектура для динамических бизнес-правил

Я создаю приложение для расчета заработной платы в .NET. Одно из требований состоит в том, что правила посещаемости и отчислений должны быть максимально динамичными и гибкими. Пользователь должен иметь возможность определять свои собственные правила, где каждый сотрудник будет привязан к правилу посещаемости.

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

Мне интересно, существует ли шаблон решения\архитектуры, который позволяет мне определять и применять правила посещаемости и вычислять вычеты на их основе без написания сценариев или динамической компиляции кода C#.


.net architecture design-patterns business-logic
person Muhammad Soliman    schedule 24.08.2009    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Boo — это полноценный язык .NET с расширяемым компилятором. Айенде написал прекрасную книгу под названием "Создание предметно-ориентированных языков в Boo", в которой он обсуждает темы расширения компилятора, чтобы разрешить что-то вроде:

when User.is_preferred and Order.total_cost > 1000: 
    add_discount_precentage 5 
    apply_free_shipping 
when not User.is_preferred and Order.total_cost > 1000: 
   suggest_upgrade_to_preferred  
    apply_free_shipping 
when User.is_not_preferred and Order.total_cost > 500: 
   apply_free_shipping

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

person Anton Gogolev    schedule 24.08.2009

arrow_upward
2
arrow_downward

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

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

Вам нужно определить правила, т.е. формально сказать, какие параметры можно использовать и как их можно применять.

например. если посещаемость 90% означает вычет 5%, то вы сохраните эти 2 значения в БД. Затем ваш код получит фактическую посещаемость, найдет соответствующую строку и применит вычет. Если ваши правила не настолько сложны, что их нельзя смоделировать с такими параметрами, лучше всего использовать систему конфигурации. Затем вы можете предоставить пользователям простой графический интерфейс для настройки значений в правилах.

person gbjbaanb    schedule 24.08.2009

arrow_upward
0
arrow_downward

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

person M. Utku ALTINKAYA    schedule 24.08.2009