Непрозрачная идентификация клиента с SQL Server и NHibernate

Question

Мы разрабатываем модное в настоящее время мультитенантное приложение SaaS (общая база данных, общая схема), и есть одна вещь, которая мне не нравится в этом:

public class Domain : BusinessObject
{
    public virtual long TenantID
    { get; set; }

    public virtual string Name
    { get; set; }
}

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

Что я хочу сделать, так это полностью избавиться от этого TenantID в наших доменных объектах и ​​иметь дело с NHibernate или SQL Server.

Из того, что я уже читал в Интернете, это можно сделать с помощью CONTEXT_INFO (здесь реализация на основе NHibernate ), фильтры NHibernate , Представления SQL и их комбинации.

Теперь мои требования следующие:

• Удалить все упоминания TenantID из доменных объектов
• ... но SQL Server вставляет его в случае необходимости (думаю, это достигается с помощью ограничений default)
• ... и, очевидно, обеспечивает поддержку фильтрации на основе этого критерия, чтобы клиенты никогда не видели данные друг друга
• Если возможно, избегайте представлений SQL Server.
• Иметь решение, которое прекрасно сочетается с NHibernate, MARS SQL-серверов и общим характером SaaS-приложений с высокой одновременностью

Что вы думаете об этом?

Answer 1

Я нахожу этот документ в значительной степени священным Граалем MultiTenant. http://msdn.microsoft.com/en-us/library/aa479086.aspx

Взгляните на использование одного из подходов, таких как «Shared Database Shared Schema», а затем подключитесь к базе данных, используя разных пользователей sql для каждого арендатора. Каждый пользователь sql увидит отфильтрованное подмножество данных и сможет извлечь только свои собственные данные, а при вставке данных ему автоматически будет присвоен собственный tenantID.

Вы обнаружите, что вам больше не нужно учитывать учетные данные TenantID в вашем приложении, и вы можете просто смоделировать остальные таблицы.

Answer 2

Подход, который я использую для нашего SaaS-приложения с общей базой данных и общей схемой, показан в сообщении , написанном Джейсоном Янгом.

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

В моем приложении я использую его с EntityFramework, но, к сожалению, в EF нет такой замечательной вещи, как DriverConnectionProvider, что действительно позор.