metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2009-11-22 02:15 pm

Ад со вшами жолтыми

С некоторых пор ничто так не бесит, как восход солнца вручную реализация систем типов и разного рода классов-объектов поверх уже существующих языков.

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

Формально настройки являются просто очень большим объектом с кучей полей разнообразных типов. Но из-за переопределения, к каждой сущности такой объект не привяжешь, или к каждому полю придется цеплять флаг "есть значение". Поэтому поля хранятся в словаре <имя_поля,значение_поля>. Уже цирк с конями.
Затем начинаются пляски с бубном "как бы это все аккуратно показать в GUI". Нарисовать руками редактор с закладками для 100 полей - увольте, я сдохну это поддерживать, если что-то добавится. Поэтому все поля показываются в гридах(ну типа как в мозиле, about:config, только по категориям разбит, чтобы юзеру проще мышой шароебиццо было). А часть настроек, сука, всякие массивы или списки типа "список подписей и расположения полей в отчетных гридах" или "список кастомных полей документа с подписями и типами". И все это при аккуратной реализации (чтобы было удобно юзеру и не требовало стояния на ушах при поддержке) настолько удалбывает - не передать.

Это еще хорошо, что 2/3 кода для этой пакости генерируется прямо из специальной базы данных, где вся эта модель конфигурации описана и редактируется культурно прямо в гриде, а не блин редактированием тысячестрочных исходников и SQL запросов.

[identity profile] permea-kra.livejournal.com 2009-11-22 03:03 pm (UTC)(link)
Ребе, а на чём это ? (язык)

[identity profile] w00dy.livejournal.com 2009-11-22 05:10 pm (UTC)(link)
Для цепляния флага "есть значение" можно попользовать Nullable<>. Тобишь пишем int? Value { get ; set ; }. Если Value == null значит берём из верхнего уровня, иначе из текущего. В общем я бы сделал два класса: первый для настроек, второй для работы с ними. Первый с поддержкой xml сериализации. Второй содержит четыре экземпляра для каждого уровня и метод для вытаскивания значения аля: object GetValue (string property) ; или типизированый стаб, что удобнее, но немного напряжнее поддерживать. Оба класса при желании можно объеденить, если что.

[identity profile] wildman.livejournal.com 2009-11-22 05:45 pm (UTC)(link)
вы что EMC Documentum реализовываете?
там имено такое. объектная БД поверх реляционной. только аттрибуты переопределяются в иерархии объект - абстрактный документ - внутренний документ - внутреннее поручение...
+ для всех полей права доступа по юзверям и группам %(

а если серпом по яйцам

[identity profile] jdevelop.livejournal.com 2009-11-22 06:43 pm (UTC)(link)
перевести все эти развесистые деревянные настройки в LDAP (ActiveDirectory/OpenLDAP/whatever), и редактирование делать в виде редактирования узлов дерева? Ну или оставить грид.

/надел каску и залез в окоп/