Поделиться
Разработка СЭД: что сможет дать "Конструктор решений"
Использование решений-конструкторов не является чем-то новым – многие разработчики не раз говорили о том, что тот или иной продукт имеет функцию конструктора и позволяет на его основе создавать готовое ПО. Тем не менее, их возможности ограничены, и на деле продуктом такой работы становятся лишь весьма ограниченные по функционалу решения. Новый инструмент со старым называнием анонсировала компания "ДоксВижн", заявив, что в реальностиэто совершенно иной продукт, существенно отличающийся от своих предшественников. В чем же заключаются эти отличия и насколько новый "Конструктор решений" облегчит жизнь и интеграторам, и заказчикам?Отдельно хотелось бы обратить внимание на то, что "Конструктор решений" позволяет осуществлять новый подход к описанию состояний и ролей, предоставляет возможность переиспользования решений и их частей, имеет удобный механизм распространения решений за счет легкости создания инсталляционных пакетов, а также использует новый способ рассылки уведомлений – с помощью сервиса уведомлений.
Истина – в сравнении
На самом деле существует 4 способа разработки карточек. Первый, активно применяемый до настоящего времени - на универсальной карточке. Он примечателен тем, что не порождает новых типов карточек. Второй способ – на "Конструкторе решений". Среди его отличительных черт – визуальное проектирование интерфейса и карточки, а также минимум кодирования (с использованием скриптов). Третий способ - на основе базовой карточки того же "Конструктора решений". За счет него есть возможность создавать более сложные собственные разработческие решения, тем не менее, использующие в своей основе базовую карточку конструктора и многие его возможности. Последний способ разработки карточек – это создание полностью собственных решений с нуля. Попробуем определить, какие возможности и ограничения имеет тот или иной способ. Для начала рассмотрим метод "Универсальной карточки", поскольку изначально его возможностей практически хватало для создания полноценного решения а-ля Канцелярия.
Сравнение способов разработки на базе универсальной карточки и с помощью "Конструктора решений"
| Универсальная карточка | "Конструктор решений" | |
| Возможности построения интерфейса карточки | Ограничены стандартным набором вкладок/полей и возможностью добавления собственных свойств | Не ограничены |
| Хранение данных | Хранение нестандартных данных возможно только в свойствах | Возможно хранение и в свойствах, и в полях |
| Описание поведения | С помощью изолированных скриптов на VB | С помощью скриптов на С# или VB.Net. Все скрипты карточки объединены в общий класс. Можно писать общие методы, переменные, объявления, подключать внешние сборки |
| Возможность программировать отклик на события | Поддерживается лишь небольшой перечень событий от DocsVision | Поддерживаются все события формы карточки и ее контролов и дополнительно набор событий от DocsVision |
| Обращение к данным в скриптах | Через ObjectManager | Через удобную более высокоуровневую объектную модель |
| Возможности настройки прав доступа | Только для объекта целиком | На отдельные операции и поля карточки |
| Ведение истории операций с карточкой | Нет | Автоматически. Есть стандартный контрол, показывающий всю историю изменений |
| Настройка уведомлений | Нет | Настраивается с помощью шаблонов уведомлений |
Источник: "ДоксВижн", 2011
Теперь рассмотрим случай, когда функциональных возможностей универсальной карточки недостаточно для создания решения, и приходится разрабатывать полностью новую карточку с помощью либо DeveloperStudio, либо конструктора решений. При этом при разработке в DeveloperStudio карточка может быть создана двумя путями: с нуля и на основе базовой карточки конструктора.
Сравнение способов разработки карточек с нуля и на конструкторе решений
| Разработка с нуля | Разработка с использованием базовой карточки | Конструктор решений | |
| Связывание контролов с данными | Необходимо программировать | Необходимо программировать | Встроенный механизм |
| Хранение данных | В полях | В полях | Возможно хранение и в свойствах, и в полях |
| Доступ к данным | Необходимо реализовывать через ObjectManager | Необходимо реализовывать через ObjectManager | Встроенный механизм |
| Описание поведения | Кодирование на С#, VB.Net или VB Кодирование на С#, VB.Net или VB | С помощью скриптов на С# или VB.Net. Все скрипты карточки объединены в общий класс. Можно писать общие методы, переменные, объявления, подключать внешние сборки | |
| Ведение истории операций с карточкой | Нет | Автоматически. Есть стандартный контрол, показывающий всю историю изменений | Автоматически. Есть стандартный контрол, показывающий всю историю изменений |
| Возможности настройки уже готового решения | |||
| Настройка различных дизайнов | Нет | Настраивается в справочнике разметок | Настраивается в справочнике разметок |
| Настройки отображения контролов | Нет | Настраивается в справочнике разметок. Ограничения: только видимость, размер, местоположение, текст метки | Настраивается в справочнике разметок |
| Выбор дизайнов в зависимости от вида, роли, состояния | Нет | Настраивается в справочнике разметок | Настраивается в справочнике разметок |
| Настройка автомата состояний | Нет | Настраивается в справочнике ролей | Настраивается в справочнике ролей |
| Настройка ролей | Нет | Настраивается в справочнике ролей | Настраивается в справочнике ролей |
| Настройка прав доступа | Нет | Настраивается в справочнике ролей | Настраивается в справочнике ролей |
| Настройка уведомлений | Нет | Настраивается с помощью шаблонов уведомлений | Настраивается с помощью шаблонов уведомлений |
Источник: "ДоксВижн", 2011
Приведенный выше анализ показывает, что метод с использованием "Конструктор решений" является более удобным, быстрым и функциональным способом разработки. Кроме того, в случаях, когда возможностей встроенного вконструктор способа работы с данными недостаточно и требуется программирование под конкретную сложную задачу, "Конструктор решений"может предоставить для разработки в качестве основы базовую карточку с богатым встроенным функционалом и всеми основными возможностями по настройке.
Практическая ценность
Теперь поговорим подробнее об использовании особенностей конструктора и применении разных способов разработки.
Олег Баранов окончил в 1989 году Санкт-Петербургский Государственный Технический Университет, начинал свой путь в ИТ-сфере разработчиком отечественной системы автоматизированного проектирования печатных плат ПРАМ 5.3. С 1995 года трудился в компании Typhoon Software, занимался системами искусственного интеллекта и IP-телефонии. В 2000 году пришел на работу в компанию Digital Design, где стал заниматься задачами электронного документооборота, руководил проектами по внедрению и отделом по разработке информационных систем. С 2008 года работает в компании "ДоксВижн" и занимает должность директора по продуктам и решениям. Олег является идеологом создания "Конструктора решений".
Одним из самых серьезных преимуществ нового инструмента является возможность быстрого прототипирования будущей системы для заказчика. Описав задачу формально и выделив необходимые объекты, можно сразу переходить к их визуальному созданию. При этом за достаточно короткий период времени можно создать работающий прототип.Для этого необходимо нарисовать интерфейс объектов и установить связи между ними, настроить права доступа, после чего разработчик получает уже работающее приложение, умеющее редактировать и сохранять самые разные данные и может продемонстрировать его заказчику, обсудить с ним детали. Хотелось бы отметить, что при создании решения нет резона удалять прототип. В дальнейшем для созданных карточек потребуется лишь описать привычную XML-схему, привязать интерфейсные элементы к полям вместо свойств, и добавить логику с помощью скриптов.
Короткая ссылка
