Почему разделение данных пользователя и профиля считается хорошим?

Question

Я читал этот вопрос и чувствовал, что не совсем согласен с утверждением Separation of user and profile data is a nice touch.

На мой взгляд, данные профиля, такие как, например, страна или все, что принадлежит пользовательскому объекту, а разделение таких данных на профиль приводит к созданию нового объекта (и таблицы) с отношением 1: 1 к пользовательскому объекту Такое разделение считается хорошей практикой только по эстетическим причинам? (Вы видите только входные данные пользователя в одной таблице, а сгенерированные данные - в другой)

Answer 1

Что ж, это только в том случае, если вы предполагаете, что пользователь и профиль имеют отношение 1: 1.

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

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

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

Это логическое обоснование, если отношения 1 к 1 гарантированно сохраняются. Может ли это?

Если вы разрешаете использовать несколько учетных данных (или несколько методов входа) для каждого пользователя, теперь это становится более интересным. Например, сеансы на основе файлов cookie часто хранятся в энергозависимом хранилище на стороне сервера (редко требуется постоянство этих данных). Хотите ли вы, чтобы эта информация указывала на объект пользователя или объект профиля?

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

Наконец, что если вы используете решение, такое как Facebook, которое позволяет использовать несколько адресов электронной почты для входа на пользователя и, скажем, дополнительно входить через OpenID и через приложение iPhone / Android? Согласитесь ли вы, что Профиль и Пользователь остаются прежними?

Answer 2

Есть несколько причин, по которым я могу подумать о разделении пользовательских данных:

1. Отделение авторизации от информации. Это то, что я настоятельно рекомендую.Как только пользователь аутентифицирован, вы смотрите только на профиль пользователя.Разделив часть авторизации, вы можете легко перейти от входа с паролем к добавлению Facebook Connect, аутентификации OpenID и т. Д., Не внося никаких изменений в объекты профиля пользователя.
2. Разделение публичного и частногоdata. В базах данных с высокой степенью защиты вы можете зашифровать личные данные с помощью закрытых ключей (чтобы только данные могли когда-либо считывать данные сам пользователь), но при этом иметь доступ к общедоступным данным как другой пользователь.
3. По соображениям производительности. Если у вас огромные объемы данных о пользователе, вы можете разместить данные, к которым сам по себе редко обращаются, чтобы индексы можно было оптимизировать для часто просматриваемых данных.вверх.

Answer 3

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

Answer 4

Для меня пользователь: Логин (Имя пользователя), Пароль, Роль и используется для выполнения всех связанных с безопасностью вещей.

«Профиль» - это дополнительная информация для пользователя, которую следует поместить в отдельный объект.

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

Answer 5

Если у вас есть публичный API (как, например, в твиттере или фейсбуке), вы хотите вернуть только данные пользователя, а не объект пользователя (содержащий защищенные данные).Это можно сделать либо с помощью отдельных объектов, либо с помощью DTO.

Answer 6

Плюсы:

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

Минусы:

1. Еще одна таблица БД или другой объект данных для хранения профиля
2. Вы должны поддерживать связь между профилем и данными пользователя.
3. Больше кода.
4. При доступе к данным профиля может произойти падение производительности.

Например, Django (веб-фреймворк Python) предоставляет механизм аутентификации, и вы можете добавить свой собственный механизм профиля.

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