моделирование разных пользователей - PullRequest
0 голосов
/ 05 декабря 2010

Мне нужен совет специалиста. Мне нужно смоделировать различные типы пользователей для моего веб-приложения, и я не уверен, как лучше всего это моделировать. Основными пользователями приложения являются терапевты. По сути, есть пользователи приложения. Итак, я могу создать таблицу терапевтов / объект домена и therapistDAO, или вместо этого я сохраняю общую пользовательскую таблицу / userDAO и вместо этого использую типы / имена ролей? Кажется странным иметь общую пользовательскую таблицу и методы DAO, всегда ссылающиеся на userTable, когда все запросы будут относиться к таблице терапевта. Например, метод возврата всех типов терапии, предлагаемых терапевтом, будет findTherapyTypes (therapist, therapistId). Тем не менее, если я использую пользовательские таблицы и объект домена пользователя, метод будет findTherapyTypes (User, userId), который кажется неправильным Если я использую универсальный объект «Домен пользователя», то у него будет список типов терапии, который не будет корректным, поскольку в будущем другой тип пользователя, например, скажет «Пациент», и в этом случае список типов терапии всегда будет нулевым, как это было бы применяются.

В будущем могут появиться другие типы пользователей, например, Пациент или клиент, кто оставил отзыв на основании лечения, полученного терапевтами?

Я буду использовать Hibernate, поэтому подумывал об использовании отображения наследования для разных типов пользователей, поскольку класс терапевта расширяет базовый класс User и реализует интерфейс пользователя с общими свойствами, такими как имя, фамилия и т. Д.

Любая обратная связь будет принята с благодарностью :):)

спасибо Mark

1 Ответ

1 голос
/ 05 декабря 2010

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

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

Я предлагаю (если у вас более одного типа пользователей) создать таблицу User (со всеми общими полями и коллекциями), таблицу Therapists и таблицу Patients. Используйте отображение наследования Hibernate (http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html), и ваш дизайн должен оставаться чистым и легко расширяемым. Я бы рекомендовал стратегию «Таблица для подкласса», но это, вероятно, только личное предпочтение.

...