Почему разделение пользователя и данных профиля рассмотрено хорошим?
Я читал этот вопрос и чувствовал, что не вполне соглашаюсь с оператором Separation of user and profile data is a nice touch.
Поскольку я вижу его, представляю данные, такой как, например, страна или независимо от того, что принадлежит пользовательского объекта, в то время как разделение таких данных в профиль приводит к созданию нового объекта (и таблица) с 1 к 1 отношением к пользовательскому объекту. Такое разделение считают хорошей практикой просто из-за эстетических причин? (Вы видите только данные ввода данных пользователем в одной таблице, и сгенерированные данные находятся в другом),
6 ответов
Что ж, это только в том случае, если вы предполагаете, что пользователь и профиль имеют отношение 1 к 1.
Если это гарантировано всегда, то причина разделения может быть чисто эстетической, но все же могут быть причины для разделения этих двух частей.
Например, данные профиля могут быть доступны другим пользователям, их можно часто кэшировать, не уделяя особого внимания быстрому аннулированию и т. Д.
Это концептуально разные типы данных, даже если они связаны один-к-одному. Я бы никогда не кэшировал данные для входа в систему, но тогда я бы не стал программно предоставлять их модулям, которым просто требуются данные профиля.
Это логическое обоснование, если можно гарантировать соблюдение отношений один-к-одному. Может?
Если вы разрешите несколько учетных данных для входа (или несколько методов входа) для каждого пользователя, это станет более интересным. Например, сеансы на основе файлов cookie часто хранятся в энергозависимом хранилище на стороне сервера (необходимость в сохранении этих данных возникает редко). Будет ли у вас эта информация, указывающая на объект пользователя или на объект профиля?
У вас может быть однонаправленная связь - есть указатель от пользователя к профилю, но не от профиля к пользователю. Таким образом, модули, содержащие данные профиля, не могут изменять данные для входа.
Наконец, что, если вы воспользуетесь таким решением, как facebook, позволяющим использовать несколько адресов электронной почты для входа в систему для каждого пользователя, и дополнительно скажете вход через OpenID и через приложение iPhone / Android? согласны ли вы, что Профиль и Пользователь остаются прежними?
Я могу придумать несколько причин для разделения пользовательских данных:
- Отделение авторизации от информации. Я настоятельно рекомендую это. После аутентификации пользователя вы смотрите только на профиль пользователя. Разделив часть авторизации, вы можете легко перейти от входа по паролю к добавлению Facebook Connect, аутентификации OpenID и т. Д.без необходимости вносить какие-либо изменения в объекты профиля пользователя.
- Разделение публичных и частных данных. В базах данных с высоким уровнем безопасности вы можете захотеть зашифровать частные данные с помощью закрытых ключей (чтобы только сам пользователь мог когда-либо читать данные), сохраняя при этом возможность доступа к общедоступным данным как другой пользователь.
- По соображениям производительности. Если у вас есть огромные объемы данных о пользователе, вы можете разместить данные, к которым редко обращаются сами по себе, чтобы индексы могли быть оптимизированы для данных, которые часто просматриваются.
Для меня пользователь: логин (имя пользователя), пароль, роль и используется для выполнения всех действий, связанных с безопасностью.
«Профиль» - это дополнительная информация для пользователя, которая должна быть помещена в отдельный объект.
И учтите: в некоторых случаях у пользователя может быть более одного профиля ...
Плюсы:
- Вы можете свободно изменять схему таблицы профиля и не беспокоиться, если это сломает пользователя.
- Вы можете повторно использовать логику аутентификации / авторизации в других приложениях.
- Вы можете связать одного пользователя с разными профилями и даже с другими приложениями.
- Лучшая производительность за счет небольших объемов данных в пользовательском объекте (применимо к хранилищу БД, где меньше столбцов в таблице лучше) во время операций аутентификации и других операций, выполняемых только пользователем, которые не требуют данных профиля.
Минусы:
- Еще одна таблица БД или другой объект данных для хранения профиля
- Вы должны поддерживать связь между профилем и данными пользователя.
- Еще код.
- При доступе к данным профиля может произойти снижение производительности.
Например, Django (веб-фреймворк Python) предоставляет механизм аутентификации, и вы можете добавить свой собственный механизм профилей.
Обычно, если профиль небольшой и никогда не будет изменяться, вы можете сохранить его вместе с данными пользователя. Если схема профиля может быть изменена в будущем или если она содержит много данных, то лучше разделить пользователя и профиль.
В основном потому, что данные профиля не требуется, если кто-то хочет просто знать, кто создал некую сущность. Единственное реальное место, где нужен профиль пользователя, - это в первую очередь, когда система хочет что-то настроить для этого пользователя, когда они находятся в системе. Представьте, что у профиля есть любимый цвет пользователей, это не имеет значения для многих или всех других применений приложения.
Если у вас есть публичный API (как, например, у twitter или facebook), вы хотели бы возвращать только данные пользователя, а не объект пользователя (содержащий защищенные данные). Это можно сделать либо с помощью отдельных сущностей, либо с помощью DTO.