Является ли аутентификация проблемой моего домена или моего приложения? - PullRequest
1 голос
/ 03 декабря 2009

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

$user->authenticate($authenticator);
$user->login($authenticator);

Где $ authenticator - это интерфейс моей службы аутентификации.

Или это будет сквозная проблема, и я бы сделал это наоборот.

$authenticator->authenticate($user);
$session->setUser($user);

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

Ответы [ 3 ]

3 голосов
/ 03 декабря 2009

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

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

Это не значит, что вы не можете иметь дело с аутентификацией объектно-ориентированным способом.

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

Я не могу помочь с php-ориентированными вещами, но в .NET безопасность - это почти то, что просто обрабатывается платформой, если вы делаете это правильно. Здесь это действительно междисциплинарная проблема при реализации, так что это делается в другом месте (FWIW).

1 голос
/ 03 декабря 2009

Сцепление

$user->authenticate($authenticator);
$user->login($authenticator);

Инверсия управления

$authenticator->authenticate($user);
$session->setUser($user);

Связь плохая, инверсия хорошая. Иди с последним.

1 голос
/ 03 декабря 2009

ИМХО прохождение Аутентификатора плохо ОО. Почему пользователь должен понимать, как аутентифицировать себя? Это пользователь, которому даже не нужно знать, что такое аутентификатор. Кроме того, прохождение аутентификатора кажется мне странным, если только вы не планируете использовать разные способы аутентификации пользователя, и, следовательно, вам необходимо передать разные типы аутентификаторов вашему пользователю. Создается впечатление, что аутентификация не является основной частью вашего приложения, поэтому я сомневаюсь, что у вас будет более одного способа аутентификации пользователя.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...