Динамическая проверка с использованием пользовательских правил

Question

Я использую языки .Net уже 4 года. Я разрабатываю трехуровневые и пятиуровневые приложения с использованием WCF, ASP.NET для веб-приложений и C # для приложений Windows. Каждый раз, когда я запускаю проект, важны бизнес-правила и проверки.

Где я должен разместить пользовательские правила проверки (события нажатия кнопки, загрузки страницы или в методах установки / получения в моих классах)?

Если проект большой и есть только поле, в котором вместо 5 символов должно быть 7 символов - зачем мне перестраивать весь проект (или проект бизнес-классов)?

Я думаю, что если бы у меня был файл, в котором были мои собственные правила, тогда, когда нужно изменить, я мог бы просто поместить в него новое правило. Я прочитал некоторые статьи в Интернете, которые предлагают для этой цели файл на основе XML, но это кажется проблематичным, потому что:

• Нет Intellisense и ошибки в файле XML очень трудно найти
• Мы должны написать собственные парсеры XML
• Поскольку этот метод требует многократных приведений, он очень медленный

Мой вопрос:

Существует ли шаблон проектирования или что-либо еще, использующее методы .NET (отражения, деревья выражений, лямбда-выражения, динамика, создание библиотек DLL и т. Д.) Для динамической проверки с использованием пользовательских правил?

---

Редактировать 1)

А как насчет атрибутов? Можем ли мы использовать их с проверками Reflection to Custom? Можем ли мы проверить свойство по другому свойству (пример формы P1 должен быть P2 + 1) с этим подходом?

Answer 1

Лучший способ обозначить бизнес-правила - это xml. Чтобы в полной мере воспользоваться этой нотацией, вам следует начать с определения структуры модели данных механизма правил, то есть ответить на эти вопросы.

1. Каковы правила?
2. Можно ли классифицировать правила?
3. Содержат ли правила общие свойства (атрибуты), такие как допустимые значения, формат и т. Д .?

Как только это будет сделано, создайте фиктивные правила xml и затем создайте схему xml на основе этого xml. Инструмент xsd.exe может помочь вам в создании схемы. Схему проще создать, если вы можете использовать такие инструменты, как Altova XmlSpy .

Что касается ответов на ваши конкретные вопросы,

• Мы не можем использовать Intellisense, и если у нас есть ошибка в XML-файле, ее очень трудно найти.

После создания схемы Visual Studio предоставляет широкие возможности для создания XML (включая intellisense и проверку).

• Мы должны написать пользовательские парсеры xml

Не требуется, класс XmlSerializer предоставляет логику для сериализации / десериализации, т. Е. Для преобразования правил xml в модель данных правил и наоборот.

• Поскольку этот метод требует многократного применения, он очень медленный

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

Если у вас нет строгих критериев производительности, XML-подход является предпочтительным способом реализации механизма правил. Помните, что чем слабее связана ваша архитектура, тем выше гибкость во время выполнения, но это отрицательно сказывается на производительности.

Пример правила

<RulesEngine>
  <Rules>
    <Rule Id="Rule1">
      <Function>
        <Equals>
          <Property name="Property1" classId="MyClassId"/>
            <Sum>
              <Property name="Property2" classId="MyClassId"/>
              <Constant type="UInt16" value="1"/>
            </Sum>
          </Equals>
        </Function>
      </Rule>
    </Rules>
    <Classes>
    <Class name="MyNamespace.MyClass" Id="MyClassId">
      <Property name="Property1" type="UInt16"/>
      <Property name="Property2" type="UInt16"/>
    </Class>
  </Classes>
</RulesEngine>

Механизм правил должен интерпретировать это правило и соответствующим образом вывести значение.

Answer 2

Взгляните на FluentValidation .Он использует выражения, и вы можете создавать условные проверки (например, проверять эти свойства, если , что соответствует некоторым критериям).FV, возможно, не так динамичен, но вы получаете Intellisense, выразительность и безопасность типов.Это общая природа означает, что он работает достаточно быстро.Вы можете внедрить некоторую динамику времени выполнения, передав делегаты валидации или пользовательские валидаторы, которые могут делать практически все, о чем вы только можете подумать.

Это означает, что вам придется перекомпилировать, но вы можете поместить валидаторы вотдельная сборка.И имеет смысл, чтобы валидатор , а не был включен / в классе, потому что вы часто обнаруживаете, что валидация выполняется в context .Например, автомобиль может быть действительным, если у него есть все колеса.Но если вы пытаетесь водить его, и у него нет газа, то он "недопустим" для вождения.Тем не менее, я бы нашел правила «близко» к тому, что они проверяют, поскольку они являются частью вашего домена.