2010-06-21 3 views
1

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

Когда пользователь становится «аутентифицированным» или его «учетные данные» изменяет в пользовательском классе Symfony, регенератор() вызывается в текущем используемом классе хранения. Класс store расширяет sfStorage.

Теперь, когда эта команда регенерации() запущена, нам необходимо выполнить некоторую бизнес-логику. Ниже приведены варианты я придумал до сих пор:

  • Измените три функции, addCredential, removeCredential, setAuthenticated и сказать им, чтобы отправить событие (setAuthenticated уже делает), поэтому мы знаем, чтобы сделать нашу бизнес-логику ,

  • Второй вариант - расширить класс sfSessionStorage и сообщить ему, чтобы он генерировал событие для каждого регенератора. Проблема с этим заключается в том, что sfUser запрашивает интерфейс sfStorage. Если мы не изменим sfStorage, то если кто-то передал какой-либо класс, который расширяет sfStorage, который не знал, чтобы добавить событие, это не сработает.

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

У кого-нибудь есть предложения?

ответ

0

Я бы пошел со вторым вариантом и расширил класс sfSessionStorage, а затем использовал класс, вставив его в factories.yml.

Это не должно вызывать проблем с sfUser, хотя, поскольку ваш собственный класс хранения будет расширяться от sfStorage по прокси.