ООП Дизайн: где должна быть повторная проверка?

Question

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

Проблема в том, что я не уверен, куда поместить логику проверки. На данный момент у меня есть класс BuyMembership, который проходит проверку по методу Buy (). Однако это не будет вызвано в начале мастера, где мне нужно проверить, является ли пользователь уникальным и имеет ли право на покупку членства.

Для этой проверки я создал класс BuyMembershipValidation, который проверяет, имеет ли пользователь право.

Теперь проблема в том, что мне нужно передать другой объект параметра классам BuyMembershipValidation и BuyMembership. Это означает, что данные разделены.

Есть ли лучший способ сделать это? Стоит ли загружать только часть информации в класс BuyMembership для первоначальной проверки, а затем загружать остальную часть после?

Обновление:

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

Другое обновление:

Я добавил ответ своим решением.

---

ТИА, Джонатан.

Answer 1

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

• Аутентификация: проверка того, что пользователь известен
• Авторизация: обеспечение доступа пользователя к определенной логике в вашем приложении
• Валидация: проверка правильности / безопасности данных, введенных пользователем, / ожидаемых или необходимых данных

Answer 2

Валидатору обычно поручено проверять предоставленную пользователем информацию, а не авторизацию. Принцип единой ответственности требует, чтобы в вашем случае они обязательно передавались двумя объектами.

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

Мои 2 цента.

Answer 3

Я решил пойти только с одним классом. Причина в том, что в методах IsElitable и Buy есть общая логика / поведение. Один определяет, соответствуют ли входные данные требованиям приемлемости, а другой проверяет, что все детали, необходимые для покупки членства, действительны. На самом деле я не вижу в этом никакой аутентификации. Аутентификация выполняется в отдельном веб-элементе управления, и я просто проверяю Identity.IsAuthenticated и имя пользователя, чтобы убедиться, что они вошли в систему. Затем я проверяю их имя пользователя и, если они имеют право на покупку, я разрешаю им продолжить, в противном случае отображается сообщение об ошибке , С точки зрения проверки входных данных у меня уже есть элементы проверки на моей веб-странице, но проверка, которой я занимаюсь здесь, является проверкой бизнес-логики на стороне сервера. По этой причине я думаю, что это должно быть в классе бизнес-логики. Не какой-то класс проверки, отдельный от логики, которая выполняет платеж. Это может быть просто мой взгляд на это, но я думаю, что это хорошо согласуется с идеями BDD о сохранении валидации внутри объекта, который содержит данные.

Answer 4

Аутентификация пользователя - это широкая тема. Это действительно зависит от того, какой тип приложения вы создаете. Если это веб-приложение, я бы рекомендовал использовать один из стандартных методов аутентификации: NTLM / kerberos

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

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