Доступные значения на основе правил для свойства в модели - PullRequest
1 голос
/ 07 марта 2012

У меня есть вопрос относительно того, где поместить доступные значения определенного свойства в класс модели. Представьте, что у вас есть класс модели, который имеет два свойства Family и Series, где возможные значения свойства Series зависят от значения свойства Family.

Бизнес-логика содержит набор правил, определяющих, какие значения Series доступны из-за значения, указанного в свойстве Family. Сама модель всегда должна иметь допустимое состояние, то есть если значение свойства Family изменяется, а доступные значения свойства Series также меняются, значение самого свойства Series должно быть изменено на одно из доступных значений, чтобы соответствовать действительное состояние.

Мое намерение состоит в том, чтобы отобразить доступные значения в ComboBox как для свойства Family, так и для свойства Series. Но на данный момент я не уверен, стоит ли ставить доступные значения свойства Series

  1. в ViewModel,
  2. в модель,
  3. или для введения отдельного слоя между ViewModel и Model, который охватывает проверку данных и функциональность предоставления доступных значений для определенных свойств в модели (которая действует как простой контейнер данных).

Я склонен использовать второй или третий подход (я предпочитаю третий подход) из-за напрямую зависимых значений в модели. Этот пример на самом деле очень прост. Реальная проблема охватывает около 200 значений, где доступные значения одного свойства могут зависеть от 5 или 10 других свойств.

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

Какой, по вашему мнению, лучший подход? Есть ли другой (лучший) способ решения этой проблемы, о котором я не упомянул выше?

Спасибо

Оливер

1 Ответ

1 голос
/ 07 июня 2013

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

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

Поэтому, на мой взгляд, лучшим "слоем" или сервисом может быть лучший вариант.

...