Привет!

Вот уже неделю мучаюсь над проблемой как бы поправильнее организовать объектную можель моей программы.
Очень хотелось бы услышать чужие идеи на этот счет.

Задача такова.
Имеется сущность внешнего по отношению к PC устройства.
У устройства есть Settings (скажем Настройки), кажое из которых имеет положим уникальный идентификатор (имя) и может принимать значения. Значения и соотв. Настройки бывают разных типов (ну например строка, слово (целое два байта), двойное слово (целое 4 байта) и другие типы).
Устройства тоже бывают разных типов и для программы отличаются наобром Настроек. Настроки в устройствах разных типов могут быть одинаковыми или разными произвольно (одношение многие ко многим). Вообще-то программа узнает о том, какие настройки поддеживаются устройством с помощью предварительного запроса о модели устройства, а затем читает описание поддерживаемых данным устройством Настроек из библиотечного положим XML файла.

Главная задача программы читать и записывать значения указанных настроек.
Кроме того, Настроки могут быть установлены с помощью различных протоколов (в зависимости от того как подключено устройство и не только, ну например через SNMP или особенным протоколом через USB и т.п.). Одни и те же настройки одного и того же устройства могут быть установлены через несколько доступных для данного устройства протоколов. Некоторые настроки могут быть установлены/считаны используя только определенный протокол.
Для клиента объектной модели по большому счету не важно как сгруппированы Настройки, они для него все на одно лицо: пара Id — значение, преобразуемое в строку.
Осложняет задачу то, что некоторые настройки имеют тип перечисления а некоторые (причем для всего-лишь одного протокола из положим 5ти поддерживаемых на данный момент) -- сложный тип, т.е. например структура или (что более важно) список. Настройка-Список представляет собой список _групп_ других Настроек. Естевственно в пределах списка все группы обладают одинаковым набором Настроек (как бы тип элемента списка), но в разных списках могут быть разные "типы" групп настроек. Добавление удаление элементов списка разумеется должно быть поэлементно (но тогда кто должен знать о типе добавляемого элемента? не хотелось бы чтобы об этом знал клиент (здесь начинаются вопросы )).
Ну и вдобавку (чтобы совсем все усложнить) устройство может иметь несколько "Интерфейсов" (например сетевой, LPT и т.п.), каждый из котрых может поддерживать вобщем-то непредсказуемые заранее "Протоколы", через которые (интерфесы и протоколы одного устройства) иногда! могут устанавливаться одни и те же Настройки.

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

Кое как модель я замутил. Получилось сложно, многосвязно, но вроде все укладыватся. кроме.. кроме этих Списков-Настроек и перечислений. Клиент модели по моей задумке должен знать минимум о типах Настроек (в этом я сомневаюсь), а в случае со списками (и перечислениями) так не получается, потому что клиенту, чтобы добраться до значений элементов списка необходимо знать о типе элемента списка. Т.е. в общем случае обращение к объектной модели должно выглядеть примерно так:

aDevice.Settings["Name"].Value = X;

В зависимости от типа настройки и типа X будет вызываться переопределенный вариант свойства Value.

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

aDevice.Settings["List"].Value[1].Value["Name"].Value = X;


в Бейсике видимо можно было бы переписать
aDevice.Settings["List"][1]["Name"] = X;

но в строго-типизированном языке как С#, на котором пока я и пишу пока что эту муть, надо будет писать
((MyCollection)((MyCollection)aDevice.Settings["List"].Value)[1].Value)["Name"].Value = X;

Уродливо, не так ли?

Да, чуть не забыл, модель в результате должна будет оформиться в виде COM объекта (в написании которых я полный новичек), поэтому я и не хочу перегружать клиентский интерфейс COM объекта определением лишних (?) типов (типов элементов списка), которые к тому же в будущем могут появиться новые (для новых моделей устройств и новых типов Настроек), т.е. все должно укладываться в примитивные типы и несколько (один?) универсальных контейнерных типов. Правда тут мне не ясно как лучше поступить с перечислениями

Каким клиентским интерфесом должна была бы обладать такая модель?
Как бы вы реализовали такую модель?

Прошу прощения за многословность и запутанность и благодарю за все высказанные идеи.

С уважением, Сергей.