Как отделить пользователя от данных приложения

Question

Я участвую в новом запуске с некоторыми друзьями из школы, и я разрабатываю REST API в качестве исходного кода для веб-приложения/веб-сайта. Недавно я ухаживал и не имел большого опыта работы с крупными проектами.

Не вдаваясь в подробности о конкретной бизнес-идее, это будет своего рода услуга «share economy», например, например, uber или airbnb, где пользователи регистрируются как клиент или поставщик конкретной услуги. Таким образом, пользователи должны регистрировать учетную запись и иметь данные, относящиеся к этой учетной записи.

API разработан с использованием ASP.NET Web API. Для аутентификации/авторизации я использую идентификаторы ASP.NET и JWT в качестве маркеров-носителей Oauth с промежуточным программным обеспечением OWIN OAuth.

Я использовал руководство для части установки, с некоторыми изменениями в соответствии с нашим проектом . (Просто выполните поиск «bitoftech». Внесите OAuth JSON Web Tokens Authentication в ASP.NET Web API и Identity 2.1 «чтобы найти его, если вам интересно».

Для тех, кто не знает, база данных ASP.NET Идентичность выглядит следующим образом: ASP.NET Identity database diagram.

Так у нас есть таблица AppUser, которая представляет пользователь, с ролями, претензиями и логинами прикрепленных в разных таблицах база данных Identity.

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

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

Каждый пользователь имеет роль клиента или поставщика (как у клиента или водителя в примере Uber) в таблице IdentityRole. Таким образом, я могу авторизовать пользователей на основе роли, а также запрашивать данные на основе роли.

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

Итак, если первым сайтом было uber, теперь мы хотим создать airbnb (не совсем, а в качестве примера).

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

Итак, сначала я подумал: «Как я могу изменить существующую схему базы данных так, чтобы она соответствовала обеим сервисам?». Но поскольку я думал об этом больше, я думаю, что это, возможно, только создаст проблемы в будущем.

В Oauth flow diagram у вас есть отдельный сервер ресурсов и сервер авторизации.Хотя я использую Oauth сейчас, мой API - это как сервер ресурсов, так и сервер авторизации, я думаю, и, вероятно, было бы хорошо, если бы они не были связаны так, как я описал?

Так что мой вопрос после того, как все это это:

1:Должен ли я использовать один (отдельные) базу данных для идентификатора пользователя (IdentityDbContext), и другой базы данных для всех других данных (события, сообщения и т. д.)?

Таким образом, идентификация может выполняться на совершенно другом сервере, если это необходимо, и не привязываться к какому-либо определенному домену/сайту/сервису. Это хорошая идея?

2:Если да, то как мне создать связь между базами данных?

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

3:Должен ли я использовать отдельные базы данных для первого и второго сайта/сервиса (один для Uber и один для Airbnb, как в примере)? Или есть лучший способ?

4:Есть ли другое решение, которое я не думал о том, что было бы лучше?

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

И, наконец, не исключено, что еще больше сервисов будет «прикреплено» к пользователю Identity в будущем, если наши текущие endevours будут успешными, поэтому мне действительно нужно будущее решение этой проблемы.

Благодарим за любые ответы.

Answer 1

Такой подход представляется несколько общего:

1. Поддерживать полностью отдельную базу данных идентификаторов. Не должно быть никакого соединения ни с одной из баз данных Line-Of-Business (LOB).

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

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

4. Когда пользователь нажимает на один из ваших веб-сайтов LOB в течение N-го времени, вы можете использовать токен доступа для вызова сервера идентификации и получения самой последней актуальной демографической информации на всякий случай он изменился со времени его последнего визита. Затем вы можете сохранить эту информацию в таблице пользователя LOB, чтобы она была доступна вам в автономном режиме, например. если вам нужно нажать на маркетинговые электронные письма, у вас будет копия адреса электронной почты.

Преимущество такого подхода является разделение проблем и способность поддерживать более одного поставщика аутентификации (например, в будущем вы могли бы поддержать Facebook или Google+ логинов, а).

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