Дизайн активации электронной почты учетной записи (с учетом Hibernate)

Question

У меня есть проблема с дизайном, на которую я хотел бы получить некоторый ввод. Вот ограничения:

1. Каждый пользователь должен иметь рабочий адрес электронной почты при регистрации своей учетной записи. При регистрации учетной записи пользователя необходимо отправить электронное письмо с активацией, содержащее ссылку с кодом активации, которая должна быть выполнена для активируемой учетной записи.
2. Каждая учетная запись пользователя существует ровно в одном офисе, который существует ровно в одной компании.
3. Первый зарегистрированный пользователь из компании создает компанию и один офис. Затем остальных пользователей компании приглашает первый пользователь.
4. Компании могут взаимодействовать друг с другом, но только если активируются первые пользователи компаний (т. Е. После регистрации они нажали соответствующие ссылки активации).

Вот небольшой UML-диаграмма, как она может быть решена:

alt text http://i43.tinypic.com/2dj5bhh.png

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

Некоторые мысли и вопросы:

• пользователя и NotActivatedUser в основном совпадают. Должны ли они быть одним классом или разделены? Если они разделены, какая форма сохранения наследования Hibernate вы бы использовали?
• Если учетная запись не активирована через определенное время, ее необходимо удалить. Если это был первый пользователь, который также создал пользователей Компании и Office, оба из них также должны быть удалены. Нужны ли нам NotActivatedOffice и NotActivatedCompany? (Для чистого разделения в базе данных.)

Как бы вы разработали этот вид решения? Считаете ли вы, что важно сохранить неактивные и активные объекты отдельно в базе данных? Почему или почему нет?

Answer 1

Я бы не использовал наследование для представления состояния (активированного/деактивированного) объектов пользователя. Композиция (агрегация) здесь намного лучше.

Используя агрегацию, AbstractUser просто становится Пользователем. Вы можете захотеть смоделировать активацию с классом вместо того, чтобы загрязнять класс User с атрибутами, связанными с активацией. Таким образом, вы получаете красивую и чистую объектную модель.

На уровне базы данных вы все же можете решить сохранить два объекта в одной таблице/записи, известной как Component mapping. Или вы можете решить сохранить User и Activation в отдельных таблицах (aka Entity mapping).

Hibernate поддерживает оба типа сопоставлений, в основном это вопрос конфигурации.

Класс пользователя должен содержать следующие атрибуты:

• GivenName
• фамилия
• электронной
• активации (ссылка на объект активации)

Класс активации будет содержать следующие атрибуты:

• activationCode (строка)
• sentOn (когда был отправлен по электронной почте)
• activatedOn (по умолчанию NULL, установленные на текущую дату/время, когда пользователь нажимает на ссылку активации, говорит системе, если пользователь активировал его счет, если не нулевой)

Вы можете использовать запрос HQL, чтобы узнать, какая компания имеет по крайней мере один активированный пользователь:

from Office o 
    left join fetch o.company 
where 
    o.administrator.activatedOn != null 

Этот запрос предполагает, что у ou определили атрибут «administrator» в вашем классе Office. «Администратор» будет ссылкой на пользователя, создавшего Office. В базе данных таблица «офисы» имеет внешний ключ для записи пользователя.

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

Я также добавил атрибут sentOn в класс активации, используемый для очистки инактивированной учетной записи через определенное время (отсутствовал на вашей диаграмме UML).

Answer 2

Я бы не отделил NotActivatedUser от ActivatedUser; просто введите таблицу пользователя и введите столбец «Активирован», по умолчанию 0 (не активирован).

Одна вещь; Я бы разделил код активации на отдельную таблицу, возможно, с помощью «ActivationMethod». Это позволяет расширять возможности в будущем, если вы хотите, чтобы пользователь мог активировать свою учетную запись, отличную от электронной почты, а также служит для удаления столбца «activationCode» из таблицы «Пользователь».

Я не беспокоюсь о неактивированных офисах и компаниях; согласно вашим планам использования, как описано выше, они не должны использоваться кем-либо еще, пока этот пользователь не активирует себя (и, следовательно, офис и компанию). Один вопрос; почему вы разрешаете неактивному пользователю создавать Office и компанию? Почему бы не ограничить эту активность только активированными пользователями?

Answer 3

Лично я бы не написал два класса для активированных и неактивных пользователей, потому что это просто состояние. Если это состояние до активации становится сложным, вы можете ссылаться на состояние активации или тому подобное.

Если у вас есть флаг «OfficeOwner», вы знаете, когда удалить офис без какой-либо сложной логики.

Answer 4

Использование одной и той же таблицы для активированных и неактивных пользователей требует проверки состояния пользователя, а также офисов и компаний во всем приложении.

По этой причине я, вероятно, воспользуюсь таблицей activrequest со всей информацией, необходимой для создания пользователя, офиса и компании при активации.