public interface IPlugin
{
void Execute();
}
public class FirstPlugin : IPlugin
{
public string SomeSetting1 { get; set; }
public void Execute() { }
}
public class SecondPlugin : IPlugin
{
public string SomeSettingA { get; set; }
public string SomeSettingB { get; set; }
public string SomeSettingC { get; set; }
public void Execute() { }
}
У меня есть система, которая позволяет user выбирать один или несколько плагинов. В приведенном выше коде у меня есть интерфейс IPlugin
, который реализуется многими классами. Каждый класс может иметь свой собственный набор свойств, и каждый пользователь может настроить эти свойства.Дизайн базы данных для сохранения пользовательских настроек
Например, Пользователь A выбирает только первый плагин и настраивает SomeSetting1 на значение «ABC».
Пользователь B выбирает оба плагина, но настраивает первый модуль SomeSetting1 для плагина, чтобы иметь значение «XYC».
public class User
{
public User(IPlugin[] plugins)
{
}
}
Когда я создаю экземпляр пользователя, я хочу, чтобы получить список плагинов, которые пользователь настроил и эти модули должны быть увлажненной с тем, что пользователь настроил.
Однако я рисую пробел о том, как создать базу данных, чтобы иметь возможность хранить информацию в этом формате. Я мог бы иметь таблицу:
User | Plugin
----------------
A | ...
B | ...
B | ...
... где столбец плагина будет сериализованные представлениями плагина, который я могу десериализацию обратно в класс. Однако это кажется ужасной/взломанной идеей. Есть лучший способ сделать это?
EAV не является действительно «чистым реляционным дизайном» в том, что столбец PropertyValue оказывается довольно бесперспективным, и это сложно lt для управления ограничениями. Но для гибкого дизайна базы данных это один из немногих вариантов. Тем не менее, это не намного лучше, чем XML-блок. –
Согласитесь ... но если он хочет найти что-то вроде: дайте мне всех пользователей, которые установили Property1 из Plugin1 в «val1», тогда это единственный способ пойти с реляционной базой данных (конечно, если он использует реляционную базу данных и не что-то вроде mongodb). Во всяком случае, я изменил свой ответ: «чистый реляционный дизайн» => «более реляционный подход» –