Многопользовательское приложение, совместно использующее данные (Asp net mvc + Entity Framework + Sql Server)

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

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

Другой вариант - купить готовый к использованию многопользовательский инженерный стек с полки, установить его в Visual Studio и использовать в качестве шаблона разработки.

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

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

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

например С помощью MVC в функции global.asax AuthenticateRequest или BeginRequest вы можете проверить, кем является пользователь, а затем вычислить, какое соединение с базой данных им нужно использовать или какой ключ столбца клиента они должны использовать в КАЖДОМ запросе для этого запроса. Затем это сохраняется в переменной сеанса и т. Д.

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

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

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

Пример:

Read Only|cust1|cust2|cust3
---------+-----+-----+-----
customer1| 1   | 1   | 0
customer2| 0   | 1   | 0
customer3| 1   | 0   | 1

Write    |cust1|cust2|cust3
---------+-----+-----+-----
customer1| 1   | 1   | 0
customer2| 0   | 1   | 0
customer3| 0   | 0   | 1

Итак, в приведенном выше примере customer1 может читать и записывать (обновлять) данные customer2.

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

(Основываясь на предоставленной информации, я также склоняюсь к тому, что это может быть проблема отдельного приложения, а не только клиента. Чтобы проиллюстрировать это, замените значения «cust» в приведенных выше таблицах на App.)

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

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

Я предлагаю использовать PRISM с шаблоном дизайна Sliverlight и MVVM. PRISM разработан для такого типа составного приложения, где каждое приложение является независимым и может также взаимодействовать друг с другом через события, предоставляемые PRISM.

У вас может быть несколько подходов - поскольку приложение управляется данными, имеет смысл создать структуру базы данных, которая защищает данные даже в случае ошибок приложения.

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

Затем вам понадобится способ убедиться, что соединение с базой данных, созданное приложением, использует только соответствующее имя пользователя, которое сопоставляется с этим идентификатором клиента. Это означает, что вам нужен еще один хранимый процесс, который предоставляет вам эту информацию (возможно, с именем пользователя / идентификатором в качестве входных данных), и этот хранимый процесс должен выполняться через общее имя пользователя db. Помните, что это единственная хранимая процедура, которая должна иметь привилегии выполнения, предоставленные этому обычному пользователю базы данных.

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