2015-09-22 9 views
1

Предположим, что я работаю в крупной производственной компании. Я контролирую качество данных о продажах компании. У разных региональных менеджеров есть свои требования к продажам из своего региона. Каждый из восьми региональных менеджеров снабжает меня файлом DRL, который должен применяться только к продажам из его собственного региона, и они будут часто корректировать DRL.Как я могу применить определенные файлы DRL к определенным фактам

Предположим, что я работаю с объектами Sale, каждый из которых включает атрибут региона. Я не должен применять правила продаж из неправильного региона. Если я случайно применил правила Тихоокеанского Северо-запада к продажам долины реки Огайо, тогда меня уволят!

я могу думать о трех способов сделать это:

  1. Trust (и проверить) каждый региональный менеджер включить регион = «...» член в LHS своих правил каждый раз, когда он подаёт новый. Загрузите все файлы DRL в сеанс Kie и запустите все Sales through.
  2. Разделить мой список < Продажа > в 8 списков конкретных регионов и запускать каждый список по соответствующему файлу DRL.
  3. Проведите аннотация и реализуйте PacificNorthwestSale, OhioRiverValleySale и т. Д. О том, что файл DRL данного региона, вероятно, не будет пытаться ссылаться на региональные продажи из другого региона.

Есть ли лучший способ? Есть ли способ, которым я могу добавить другое условие LHS (region = "...") ко всем правилам в DRL? Или какой-то другой способ, которым я могу применять эту политику, не делая:

  • несколько казней правил
  • или ручной проверки, что все правила определяют соответствующий регион?

ответ

2

# 1 отсутствует, так как нет надежного способа установить ограничение области во всех правилах. (Это, конечно, заставляет задуматься: смогут ли эти региональные парни быть достаточно хорошими, чтобы правильно писать свои правила, сверх ограничений региона? Как так? Будет ли одно из этих правил рассчитать их бонус?)

# 2 is целый и невредимый. Это требует немного дополнительной обработки, но это незначительно.

# 3 делает базу кода Java излишне сложной. По сути, сопоставление с отдельными подклассами класса, при прочих равных условиях, является не чем иным, как сахарированной версией # 1. Единственное преимущество было бы в том, что проверка проще, например, вы можете запустить простой grep по каждому DRL.

# 4 - это тот, который я бы принял, если запуск всего за один сеанс более удобен тем, что требуется для # 2. Для этого, объединить DRL файлы программно, с небольшим «клеем»:

package what.ever; 
import this.and.that.*; 

agenda-group "PacificNorthwest" 
// DRL from Pacific-Northwest 

agenda-group "OhioRiverValley" 
// DRL from Ohio River Valley 

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