2012-01-13 4 views
0
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  | ... 

... где столбец плагина будет сериализованные представлениями плагина, который я могу десериализацию обратно в класс. Однако это кажется ужасной/взломанной идеей. Есть лучший способ сделать это?

ответ

1

Если вам не нужно запрашивать базу данных по некоторым свойствам, сериализованным в столбце Plugin, я не вижу в этом ужасной/взломанной идеи. Кроме того ... вы можете рассмотреть возможность использования некоторой базы данных, не относящейся к схеме, например mongodb. Во всяком случае, я бы сделал это с сериализацией (возможно, JSON-объектом, если позже я буду использовать этот результат из javascript или какой-нибудь XML, если это более подходит для вашей среды).

Если вы хотите остаться с более реляционного подхода ... тогда вы будете иметь таблицу с параметрами плагинов ... с колоннами: UserId, PluginId, PropertyName, PropertyValue ... то, таблица с плагинами: PluginId, PluginName, и ваш стол с пользователями: UserId,...and some columns for users (это только один из способов его дизайн) проблема заключается в том, если у вас есть какие-то свойства плагинов, которые являются сложными объектами ... в этом случае, вам придется сериализовать их в колонну PropertyValue ...

+0

EAV не является действительно «чистым реляционным дизайном» в том, что столбец PropertyValue оказывается довольно бесперспективным, и это сложно lt для управления ограничениями. Но для гибкого дизайна базы данных это один из немногих вариантов. Тем не менее, это не намного лучше, чем XML-блок. –

+0

Согласитесь ... но если он хочет найти что-то вроде: дайте мне всех пользователей, которые установили Property1 из Plugin1 в «val1», тогда это единственный способ пойти с реляционной базой данных (конечно, если он использует реляционную базу данных и не что-то вроде mongodb). Во всяком случае, я изменил свой ответ: «чистый реляционный дизайн» => «более реляционный подход» –

0

Столы

User 
----- 
UserID 
Name 

Plugin 
------ 
PluginID 
PluginName 

PlugInProperty 
------------------ 
PlugInPropertyId 
PluginID 

UserPlugin 
------------ 
UserPluginId 
UserId 
PluginId 

UserPlugInProperty 
------------------ 
UserPluginId 
PlugInPropertyId 
Value 
Смежные вопросы