Итак, мы создаем многопользовательскую систему для работы в качестве сервиса. Мы начинаем с нуля. Мы следим за DDD; домен имеет (на данный момент) ~ 20 объектов в нем, а позже будет больше. Он должен быть размещен нами, географически избыточным (n + 1 всего, кроме SQL-запросов ;-)), и гибкого дизайна (ну, это последнее наше требование, а не бизнес », хотя они хотят, чтобы мы могли легко изменить его по требованию). Мы основаны на .NET и будем использовать реляционную базу данных для нашего резервного хранилища. Мы не против использования инструментов и библиотек с открытым исходным кодом (вообще).Как вы подходите в .NET, позволяя арендаторам приложения SaaS с несколькими арендаторами произвольно добавлять свойства к объектам модели?
Одной из обязательных функций бизнеса является то, что некоторые объекты могут быть расширены арендаторами системы. Например, клиент A может хотеть, чтобы сущность Foo имела свойства Title и Abstract, тогда как клиент B мог хотеть, чтобы сущность Foo имела свойства публикации Date и Directed-By, а не Title Abstract.
Возможно также, что он должен поддерживать данные на нескольких языках для арендаторов, которые этого хотят - например, один арендатор может быть заинтересован в переводе всей своей учетной записи на два (или более) языка; как «статические» строки, так и строки, привязанные к объектам как данные.
So. Произвольное количество полей (помимо некоторых общих базовых значений, есть определенные вещи об этих сущностях, которые получат все арендаторы), определяемые клиентом (где они также могут определять тип данных). Возможность перевода данных (без дублирования объектов - как в, без настройки одного набора на английском языке, а затем настройка того же набора на французском языке). Сильно типизированное, доступное для поиска, запрашиваемое хранилище резервных копий (так что никакого поля extra-stuff-in-an-XML-поля не существует, если только он не сможет найти строго типизированный и доступный для поиска). Performant (но в качестве вторичного требования, эта функция достаточно важна, чтобы купить оборудование, если это необходимо).
Объем данных? В нашей нынешней системе «средний» клиент имеет сотни объектов, «большой» клиент имеет тысячи объектов. Запросы обычно отфильтровывают эти списки для отображения между 10-200ish, и наиболее распространенная вещь, которую вы хотите сделать, включает в себя, возможно, полдюжины сущностей (которые в новой системе должны быть расширяемыми).
Другие очки? Каждая организация имеет прямую ссылку на арендатора, который ее владеет.
Как это можно сделать в .NET-land? Было высказано предположение о том, что мы вставляем наши объекты в контейнер IoC и объединяем их вместе на лету во время выполнения, но как это можно сопоставить с реляционной базой данных?
Я также помню чтение Ayende's post на этом с Lucene.NET с некоторого значительного времени назад, которое звучит хорошо, но у нас нет опыта с Lucene.NET или nHibernate в настоящее время. (В настоящее время мы используем Linq2Sql для нашего ORM, но если нам нужно изменить это, чтобы поддержать это, я лично был бы счастлив, честно говоря).
Я читал this Castle dev list thread, который связан с Айенде, и кажется, что nHibernate имеет что-то, называемое IUserType, которое может помочь - интересно, можем ли мы применить это, потянув соответствующий нам IoC для каждого арендатора? Таким образом, один IUserType для каждого арендатора на расширяемый объект и хранит данные в столбце XML внутри SQL Server (наша наиболее вероятная СУБД).
Наконец, я только что прочитал одно предложение о динамическом изменении DB-таблицы на сущность на каждого арендатора - но это звучит довольно ... Чрезмерно, честно! Я имею в виду, что это может работать, но это звучит не так, как отличная идея, чтобы дать возможность сделать это жильцам (которые могут быть менее техничными). Полагаю, это может ограничиться только административными сотрудниками ...