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

[metaclass]

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

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

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

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

Comments

[permea-kra.livejournal.com]

Ребе, а на чём это ? (язык)

[metaclass.livejournal.com]

Основная прога и веб-сервис - .NET, C#
Конфигурация веб-сервиса - sqlite
Основная база данных - mssql
База данных для модели конфигурации - Firebird (ни под что больше нормального GUI-клиента нету).
Кодогенератор из модели в разнообразные sql и C# - на дельфи.

[freiksenet.livejournal.com]

Это просто ад какойто :)

[metaclass.livejournal.com]

Я ж говорю, ад с вшами разных цветов. Практически вся палитра 2^24 степени.

[freiksenet.livejournal.com]

Не хватает Cobol-а или Visual Basic-а, на крайняк )

[permea-kra.livejournal.com]

Ребе, а вы не собираетесь это переделывать?

[metaclass.livejournal.com]

Я именно этим и занимаюсь.

До того было еще хуже - конфигурация частично в mssql, частично в 150 XML файлах, редактирование оных исключительно руками в notepad2, исходный код на C# превратился в тыкву за 4 года разработки в стиле "вот срочно нужна на завтра фича" и отсутствия четких требований. Т.е. ад троекратный :)

[w00dy.livejournal.com]

Если это всё переисывать, то я бы вынес в классы и атрибуты. Потом налету вытаскиваем всё это через reflection, запихиваем в грид, добавляем валидаторы (чтобы не запихнуть строку в число), где нужен хитрый редактор (это всё прописано в атрибутах, включая тип редактора) - показываем кнопку редактирования и создаём этот хитрый редактор при нажатии. В результате чтобы добавить новую настройку достаточно только добавить её в нужный класс и нормально прописать атрибуты, а дальше оно как-нить само.

PS Можно даже окно с редактором настроек генерировать автоматом, если все знания вынести в атрибуты. Сделать что-то аля Options в Visual Studio (слева дерево, справа всё остальное)

[metaclass.livejournal.com]

Уже делал так, и даже работает.
Нечитабельно в принципе. Редактированию поддается с трудом. Нет возможности проверки валидности на уровне БД(списки ключей - только в коде).

Я сейчас делаю наоборот: данные изначально в специальной базе данных, из нее генерируются скрипты заполнения основной базы, исходный код объекта с атрибутами, код загрузки-сохранения, и прочее. А от генератора гуи для редактора я отказался - там вылазят такие кошмары, если хочется сделать что-то сложнее редактора простых типов, что проще все таки пока с гридом работать. Да, и дерево там тоже есть.

[w00dy.livejournal.com]

Для цепляния флага "есть значение" можно попользовать Nullable<>. Тобишь пишем int? Value { get ; set ; }. Если Value == null значит берём из верхнего уровня, иначе из текущего. В общем я бы сделал два класса: первый для настроек, второй для работы с ними. Первый с поддержкой xml сериализации. Второй содержит четыре экземпляра для каждого уровня и метод для вытаскивания значения аля: object GetValue (string property) ; или типизированый стаб, что удобнее, но немного напряжнее поддерживать. Оба класса при желании можно объеденить, если что.

[metaclass.livejournal.com]

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

Сейчас у меня основная война происходит с редактором GUI - там как раз получается путаница "где данные, где метаданные, а где вспомогательные объекты, чтобы это все выглядело и редактировалось культурно".

[wildman.livejournal.com]

вы что EMC Documentum реализовываете?
там имено такое. объектная БД поверх реляционной. только аттрибуты переопределяются в иерархии объект - абстрактный документ - внутренний документ - внутреннее поручение...
+ для всех полей права доступа по юзверям и группам %(

[metaclass.livejournal.com]

Нет, я как раз всеми силами стараюсь этого избежать, потому что объектная БД поверх реляционной - это мрак и его для начала хорошо было бы теоретически описать. Но у меня нихрена не выходит. "Выношу запчасти от кровати, собираю - получается пулемет".
Несколько раз в разных проектах делал - каждый раз заканчиваю на том, что при используемых инструментах реализовать требуемое силами одного человека за ограниченное время нереально.

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

[jdevelop.livejournal.com]

перевести все эти развесистые деревянные настройки в LDAP (ActiveDirectory/OpenLDAP/whatever), и редактирование делать в виде редактирования узлов дерева? Ну или оставить грид.

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

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

[metaclass.livejournal.com]

Было бы весьма заебись хорошо и энтерпрайзно.
Но деплоймент и разборки "почему у клиента что-то не работает" превратились бы в нечеловеческий ад. Так я беру свои логи или базу и смотрю что там не так. А так придется выдуривать права доступа к LDAP и пользоваться его безумными средствами запросов, чтобы найти что-нибудь.
Кроме того, ситуация делегирования прав пользователям на настройку системы включила бы в себя админа AD, которые в большинстве случаев как-то на контакт идут неохотно.

[jdevelop.livejournal.com]

/осторожно выглянул из окопа/

вариант включения в поставку ldap в виде например openldap? тот же ldap, только бесплатный, и можно плюнуть в глаза виндовому админу с его AD

или там http://directory.apache.org/

[metaclass.livejournal.com]

У меня с "готовыми" продуктами очень нерадостный опыт взаимодействия. Особенно такими глобальными. Одно дело искать ошибки в своем коде, другое дело - сначала разбираться в чужом и прикручивать его к своей задаче, потом где-нибудь наткнуться на то, что авторы были психи и какой-то нужный вариант использования не предусмотрели и нужно заниматься плясками с бубном чтобы его реализовать, а потом на продакшене разбираться, в случае чего "что случилось".

Вообще, если бы это был "домашний" проект, т.е. где можно в случае чего сесть прямо на производственный сервер и разобраться что к чему - готовое использовать было бы проще. А когда вся диагностика исключительно по обрывкам логов и невнятным переводам с басурманского, я не уверен что морально готов ставить софт, написанный не мной :)

[vk11.livejournal.com]

совершенно согласен :)
кстати, а что нынче с отказоустойчивостью и скоростью у них?