Несколько кодовых сайтов ASP.NET MVC с использованием одного и того же DB/Auth/Model/backend - как?

Question

Поэтому у меня может быть немного странная ситуация, и мне нужно руководствоваться.

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

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

Просто, чтобы быть ясным: интерфейсный для каждого сайта должен быть другим - иногда только тонко, но в некоторых случаях довольно много (маркетинговые различия). Бэкэнд (как Admin, так и клиентский интерфейс) идентичен по структуре независимо от URL-адреса сайта, но интерфейс клиента должен показывать другой контент (программы для загрузки, списки компьютеров, на которых была зарегистрирована программа, и т. Д. .) в зависимости от того, какой URL-адрес используется.

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

Я изучал районы, но районы, похоже, являются способом разделения от валовых различий в пределах сайт (такие как файлы ресурсов - JavaScript, CSS и т. Д.) Остаются в корне, тогда как в моем случае каждый сайту потребуются разные файлы ресурсов). Мне нужно, чтобы каждый раздел был его собственным уникальным сайтом с его собственным уникальным URL-адресом. Когда это нажимается на сервер, мне нужно, чтобы каждый сайт был «независимым» в том, что может сидеть в совершенно разных учетных записях на одном сервере Windows Plesk (Plesk не был моим выбором, но у компании есть клиенты, которым нужен контроль интерфейс панели к их собственным учетным записям). Единственная единственная связь между любыми из них - это база данных, которую они будут использовать - на самом деле все они будут использовать одни и те же таблицы с очень небольшим различием между сайтами.

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

Если у кого-то есть предложение, я хотел бы услышать об этом.

Answer 1

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

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

1. Если все сайты будут в одном домене (разные субдомены в порядке). Тогда вам нужно всего лишь создать машинный ключ и убедиться, что каждый сайт использует тот же машинный ключ в своем Web.config. Файл cookie auth будет добавлен в подстановочный домен, и любой подобъект этого домена сможет его увидеть. Совместное использование машинного ключа заключается в том, чтобы каждый из них мог расшифровать его, какой он устанавливает в качестве файла cookie auth.

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