Строится объектная модель некой предметной области.
Архитектура: база <-> сервер приложений <-> несколько клиентских приложений
Сложность — порядка 50 классов.
Требования: автоматизация, оперативное уведомление других клиентов, откаты, генерация базового GUI по атрибутам(проперти грид и таблица).
Варианты реализаций:
1) по старинке создать несколько параллельных иерархий и запарится их поддерживать.
2) создание одной иерархии на .NET + несколько сервисных классов на каждую фичу.
Недостаток: очень много методов set/add/remove надо реализовывать типовым образом где происходят обращения к сервисным классам, отвечающим за фичи откатов и т.п. Запаришся модифицировать.
Что делать?
Варианты:
1) Заюзать макросы и шаблоны на управляемом с++.
2) Заюзать R# или Nemerle на C#.
3) Написать всё на generic-ах типа XMLNode.
Вот и думаю какие плюсы и какие минусы того или иного подхода.
Re: Что выбрать. Кодогенерация или повышение абстракции
Здравствуйте, WoldemaR, Вы писали:
WR>2) создание одной иерархии на .NET + несколько сервисных классов на каждую фичу. WR>Недостаток: очень много методов set/add/remove надо реализовывать типовым образом где происходят обращения к сервисным классам, отвечающим за фичи откатов и т.п. Запаришся модифицировать.
К этому мы добавили кодогенерацию и deploy-time валидацию. И не паримся.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re: Что выбрать. Кодогенерация или повышение абстракции
Здравствуйте, WoldemaR, Вы писали:
WR>Начну по порядку.
WR>Строится объектная модель некой предметной области. WR>Архитектура: база <-> сервер приложений <-> несколько клиентских приложений WR>Сложность — порядка 50 классов.
WR>Требования: автоматизация, оперативное уведомление других клиентов, откаты, генерация базового GUI по атрибутам(проперти грид и таблица).
Здравствуйте, WoldemaR, Вы писали:
WR>Что делать? WR>Варианты: WR>1) Заюзать макросы и шаблоны на управляемом с++. WR>2) Заюзать R# или Nemerle на C#. WR>3) Написать всё на generic-ах типа XMLNode.
4) ПосмотретьBLToolkit
Здравствуйте, IT, Вы писали:
IT>Если я правильно понял про откат, то ещё на EditableObjects.
Да, точно. Вот я читаю:
EditableObjects – базовые классы для построения иерархий бизнес объектов, способных уведомлять потребителей об изменении своего внутреннего состояния и поддерживающих методы AcceptChanges, RejectChanges и флаг IsDirty.
Если я правильно понял там всё на делегатах.
Впрочем можете не отвечать, я всё равно буду смотреть и изучать BLToolkit.
Re[3]: Что выбрать. Кодогенерация или повышение абстракции
Здравствуйте, WoldemaR, Вы писали:
WR>Здравствуйте, Max.Subpixel, Вы писали:
MS>>К этому мы добавили кодогенерацию и deploy-time валидацию. И не паримся.
WR>Точно! Про валидацию совсем забыл. А насчёт кодогенерации то я пока только макросы да шаблоны на плюсах юзать умею. Хотя и смотрю в сторону R#.
WR>А вы чем пользуете кодогенерацию?
ja v odnom proekte uzal mygeneration http://www.mygenerationsoftware.com/portal/default.aspx
ktoto ispolzoval etot product dlja generacii DAL classov i td ?
interesno kto kakie shabloni uzaet
Re[3]: Что выбрать. Кодогенерация или повышение абстракции
В особенности обратить внимание на TypeAccessor(ну и TypeBuilder наверно).
IT>Если я правильно понял про откат, то ещё на EditableObjects.
Тут я неправильно выразился.
Под откатом я имел ввиду порождение команд для стеков Undo/Redo. Тут конечно уведомлять клиентов надо, а вот писать в базу — ни-ни.
Re[7]: Что выбрать. Кодогенерация или повышение абстракции
Здравствуйте, WoldemaR, Вы писали:
WR>Всё интереснее и интереснее. WR>База объектная, классы меняете, стеки команд передаёте... WR>Зачем, для чего, я в растерянности и сгораю от любопытства. WR>Намекните хотябы. а лучше расскажите.
Список у меня несколько иной — он отталкивается от того, что на самом деле нужно:
1. Нам нужен оффлайн режим — полноценная работа с данными пока сервера нет
База локальная — встроенная в процесс объектная база. Все происходит транзакционно. С сервера сначала сжатая копия нужной части базы (там тоже много хитростей), потом обновления оъъектами. На сервер только вызовы методов (не стек, а верхушки) подписанные сертификатами.
2. Нам нужна простота и чистота программирования и отладки.
Прощай Emit. Проверки логики всегда по месту. Чистый и простой ООП. Кодогенерация тупых мест. Реальные контролы и диалоги. И т.д.
3. Нам нужно, чтобы сервера были масштабируемы и отказоустойчивы.
Система кластера без единой точки поломки. Хот-свап серверов. Параелелльная работа в рамках кусочков базы (много баз). Ну и много чего еще.
4. Нам нужно, чтобы мы не зависели от пиковых нагрузок сервера.
Все операции с сервером асинхронны. На сервере повторно выполняется весь код, но предварительно считается, что если на клиенте прокатило, то и там прокатит. Если нет — покажем в чем проблема ползователю и поможем что-то поправить, чтобы транзакция прокатила или была отменена. Копим транзакции на клиенте. Контроллируем что данные приняты по кластеры. Придерживаем обновления.
5. Нам нужна безопасность на очень высоком уровне (в первую очередь внедрение в систему неавторизированных изменений).
Не принимаем объекты от клиентов. Только вызовы. Проверяем подпись всех данных. Проверка безопасности и логики по всему стеку. Некоторые классы нетранспортабельны и запускаются удаленно. PGP шифрация данных на клиенте. Ключ не храним.
6. Нам нужно, чтобы в системе были использованы лучшие стороны ООП в том числе — инкапсуляция, наследование.
Никогда не работает с данными и конкретными классами. Только объекты (пусть даже иногда приходится бороться за производительность).
7. Нам нужно, прозрачно работать с огромными объемами данных.
Некоторые базы локальны, некоторые нет (удаленные объекты), некоторые нетранспортабельны, но для бизнес-логики это все прозрачно и единообразно.
8. Нам нужны песочницы — возможность пользователя что-то такое наворотить, попробовать, откатить, передалать, посмотреть что выйдет и когда наиграется, например, положить это в систему.
Объектные локальные базы. Cross-DB references. Возможность работать с реальными данными в спец-режиме — когда изменяем только локальную базу, но ничего не коммитим.
9. Нам нужно легко ворочать миллионами объектов как на сервере, так и на клиенте.
Легковесные объекты, использование структур местами, грамотное проектирование ссылок (нет большим графам).
10.Нам нужно, чтобы можно было вообще работать без сервера тем же кодом — Personal Version.
Объектная БД — нет схемы, нет инсталляции. Код весь есть — кроме процессора серверных задач.
11.Нам нужен легкий и логичный PDA и WEB доступ, но функциональный и основанный на том же коде
Написание бизнес-логики на Compact Framework. Нет статических данных (кроме констант). Легковесные объекты. Базовые фабрики довешиваются доп. реализацией в зависимости от применения (PDA/WEB/DESKTOP)
12.Нам нужна глубокая и легкая кастомизация классов.
Диалоги динамические, но с возможностью настроить. Логика диалогов единая. Если не хватает — то на объектах.
13.Нам нужно недорого сделать лучший продукт в своей нише, легко развивать и сопровождать.
Ну многое сверху для этого. В первую очередь модель проста. Отказ от трудоемких работ. Отказ от преждевременной оптимизации. итд
14.Нам нужна многокультурность — рызные языки у разных пользователей одной системы, разные валюты одновременно, разные часовые пояса.
Специальные классы и подходы заранее, а не потом.
15.Нам нужна надежность кода
Юнит тесты. Простой и наглядный код, комментарии методов.
16.Нам нужна абсолютная отзывчивость клиентских частей
Асинхронные операции. Аккуратная работа с данными.
17.Нам нужна возможность работать через прокси и через файрволы
HTTP клиент и сервер. Никаких ремотингов и надстроек — все уже есть в .NET.
18.Нам нужна возможность работать при очень плохом соединении с сервером — обрывы и медленная связь
Отдельные потоки и решения заранее расчитанные на это. Упаковка данных когда надо. Архитектура в целом.
19.Нам нужно, чтобы с системой могли работать непрофессиональные пользователи
Юзабилити — простой и понятный подход. Не скрываем как работает система, а проектируем, чтобы работала так как понятно. Ховеры с кнопками ПОДРОБНЕЕ на всех контролах. Поиск по справке. Настраиваемые диалоги.
20.Нам нужно, чтобы пользователям нравилась система
Нет рецепта
ну и т.д.
WR>А я вот примерно сформулировал список функциональных и аспектных требований к нашей объектной модели:
WR>1 Синхронизация объектов между приложениями и базами, расположенных даже на разных компьютерах. WR>.Net Remouting ? — я в растерянности.
Не знаю. Мы отказались. Проще сериализовать объекты и передавать — производительность и контроль сильно выше, а плюсы ремотинга в нашем случае были не нужны.
WR>3 Описание и наименование объектов и их членов на человеческих языках. WR>.Net и атрибуты
Согласен. Но у нас недостаточно — языков много. Но дефолтный язык, там.
WR>4 Пользовательский интерфейс для объектов. Список свойств, методов и таблица. WR>.Net и генерация по атрибутам
У нас так + кастомизация руками админов/разработчиков + объекты класса диалог.
WR>5 Контроль прав пользователя на выполнение операций на объектах. WR>.Net и контроль по атрибутам
У нас кодогенерация. Лазить здесь в атрибуты слишком дорого. Но описание на атрибутах + кастомизация клиентом.
WR>6 Контроль и динамическая проверка производимых изменений. WR>.Net и валидация по атрибутам. В особых случаях — проверки вручную.
Валидацию по атрибутам мы выкинули. В атрибутах у нас подсказки редактору — какой тип, что пойдет, а что нет, минимум, который всегда статичен и позволяет не заставлять ошибаться на ранних сроках. Еще исключения — тоже подсказки редактору, если что не так. А так — валидация в самих методах и свойствах.
WR>7 Откаты изменений на объектах. Undo/Redo. WR>Порождение команд CmdAdd, CmdRemove, CmdChange от базового ICmd и укладка/вытаскивание их из стеков.
Не знаю что это. У нас кодогенерация на все свойства и методы — укладываем список того, что вызвали. Работаем с базой измененных объектов отдельно. Можем только откатить объекты а потом до нужного уровня донакатить изменения (придержав события).
WR>8 Журнал изменений. WR>Протоколирование команд. Тут я ещё сам незнаю что нам надо.
У нас требование — полный аудит. Бэкап делается автоматом на лету на сервере + храним все присланные вызовы методов/свойств, поэтому знаем кто что сделал, а не какое поле поменялось, что существенно ценнее.
WR>9 Доступ к объектам из исполняемых программ на C#, VBS, JavaScript. WR>Тут два варианта. Либо машина скриптов, либо компилятор C#.
Машина скриптов это зачем? У нас просто компиляция и кодоверификация на лету... + Редактор упрощенных моделей (когда не надо весь код писать, а только часть).
WR>10 Преобразование объектов в бинарный поток или документ XML. WR>.Net насколько я понимаю, делает это автоматически.
делает. Но совсем медленно и некомпактно. Пока мы используем сериализатор базы. Если будет своя база, то будет кодогенерация сериализатора на каждый класс (скорость в 10-100 раз).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[6]: Что выбрать. Кодогенерация или повышение абстракции
Отвечу на основной вопрос:
WR>Что выбрать. Кодогенерация или повышение абстракции
Кодогенерация (а-ка одно из проявлений метапрограммирования) есть средство повышения абстракции и уменьшения дублирования кода. Так что выбирать тут не из чего.
Просто кодогенерация иногда может решить проблемы которые сложно и неуклюже решаются другими методами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
делает. Но совсем медленно и некомпактно. Пока мы используем сериализатор базы. Если будет своя база, то будет кодогенерация сериализатора на каждый класс (скорость в 10-100 раз).
