Применение бизнес-логики к элементам формы в ASP.NET MVC

Question

Я ищу рекомендации по применению бизнес-логики для элементов формы в приложении ASP.NET MVC. Я предполагаю, что концепции будут применяться к большинству шаблонов MVC. Цель состоит в том, чтобы вся бизнес-логика происходила из одного места.

У меня есть базовая форма с четырьмя элементами:
Текстовое поле : для ввода данных
Флажок : для утверждения персоналом
Флажок : для одобрения клиента
Кнопка : для отправки формы

Текстовое поле и два флажка - это поля в базе данных, доступ к которым осуществляется с помощью LINQ to SQL. То, что я хочу сделать, это поставить логику вокруг флажков, которые могут проверять их и когда.

Правда таблица (немного глупо, но это пример):

  when checked  || may check Staff || may check Client   
 Staff | Client || Staff | Client  ||  Staff | Client 
  0        0    ||   1       0           0        1
  0        1    ||   0       0           0        1
  1        0    ||   1       0           0        1
  1        1    ||   0       0           0        1

Есть две роли безопасности: персонал и клиент; роль человека определяет, кто он, роли поддерживаются в базе данных вместе с текущим состоянием флажков.

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

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

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

Answer 1

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

, тогда, по вашему мнению, вы можете установить флаг включения, используя Model.CheckBoxName.state.

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

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

ИМО модель должна быть настолько простой, насколько это возможно.У вас может быть FormViewModel, который описывает состояние различных элементов управления, которые удаляют это состояние из модели, и я думаю, что это хорошая идея.

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

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

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

Answer 2

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

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

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

Имеет смысл?