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

Question

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

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

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

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

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

Update:

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

Другой Update:

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

---

TIA, Jonathan.

Answer 1

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

Answer 2

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

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

Мои 2 цента.

Answer 3

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

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

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

Answer 4

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

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