Модульное приложение
Одной из задач Проекта Доминикана было построение приложения, состоящего из множества модулей. Модули нужны в проекте для облегчения поддержки сложного решения и для привлечения сторонних разработчиков с целью продажи их модулей. Данная статья — это попытка выработать подход к построению модульного приложения на платформе 1С.
Принципы построения модульных приложений на примере .Net framework можно почитать здесь: http://habrahabr.ru/post/176851/
Модульный подход применим для приложений, которые будут активно развиваться во время своей жизни — для приложений, которые построены надолго и для изменений. По другую сторону от модульных приложений стоят монолитные приложения, которые трудно и неэффективно поддерживать. Слово «монолитное» указывает на приложение, в котором компоненты очень тесно связаны, и между ними нет четкого разделения.
Модульный подход позволяет разделить компоненты на слабосвязанные части и поддерживать их разными командами разработчиков. Слабая зависимость позволяет снизить конфликты между независимо добавленным функционалом в разные модули.
Несмотря на то, что 1С выпустила БСП, как шаг к модульности приложений, хотелось бы видеть несколько альтернативных подходов. В некоторых применениях БСП может не подойти.
К статье приложена выгрузка информационной базы с конфигурацией, реализующей несколько модулей и демонстрирующей процесс инициализации модулей. Выгрузка сделана для 1С версии 8.3.3.
Нахождение модулей
В предложенном решении за нахождение модулей отвечает загрузчик, который ищет модули в конфигурации и составляет из них список. Список хранится в параметре сеанса МодулиПриложения. Параметр сеанса позволяет контролировать список доступных модулей, например, в зависимости от прав пользователя или наличия подписки.
Принцип нахождения модулей предложен следующий. Рекурсивно анализируются все подсистемы. Если подсистема содержит подсистему МенеджерМодуля, то считается, что данная подсистема — это модуль. Подсистема МенеджерМодуля содержит 2 общих модуля, выполняющихся на клиенте и сервере (наличие серверного модуля обязательно). Серверный модуль должен содержать функцию ПолучитьИнтерфейсы(), которая вернет массив строк — поддерживаемые модулем интерфейсы. Интерфейсы — это перечисление функциональных возможностей данного модуля.
Проверить наличие зарегистрированного в системе модуля можно через вызов
Если МодульноеПриложение.МодульОпределен("CRM_БазаКлиентов") Тогда
Сообщить("Модуль CRM_БазаКлиентов определен");
КонецЕсли;
Наименование объектов конфигурации
Для того, чтобы при добавлении объектов конфигурации в составе модулей от сторонних разработчиков не было конфликта имен, нужно обеспечить уникальность названий в конфигурации. Так, например, у разных поставщиков может быть справочник Настройки. Невозможно добавить справочники с одинаковыми наименованиями в одну конфигурацию. Поэтому в название нужно добавить префикс или постфикс, отличающих его от аналогичных.
В предложенном подходе принято расширять имя объекта через постфикс. Строка, добавленная в конец названия, позволяет осуществлять сортировку и быстрее выбирать в коде нужный объект. Способ может быть непривычным, поскольку в большинстве случаев в 1С принято применять префикс. Но оба способа имеют право на существование.
В префикс кроме вендора-разработчика модуля может быть полезно зашифровать название модуля, потому что, скорее всего, менеджеры различных модулей в рамках одного поставщика будут иметь одинаковые названия.
Интерфейсы
При инициализации модуль возвращает список поддерживаемых интерфейсов. Интерфейс — это заявление о том, что модуль реализует набор процедур или функций с заданными именами и заданными параметрами. Разработчики могут сами придумать соглашение о том, какие интерфейсы определены и к каким методам и функциям относятся.
Система интерфейсов позволяет обеспечить слабую связанность модулей и подписку на глобальные события системы. Выгода в том, что вызывающий модуль может не знать, кто подписан на него, а вызываемый модуль не будет содержать статической ссылки на вызывающий модуль.
Сейчас для примера добавлены следующие интерфейсы. Каждому интерфейсу соответствует одна процедура или функция, но в других случаях их может быть несколько:
| Название интерфейса | Описание | Расположение |
| УстановкаПараметровСеанса | Вызываются процедуры модуля, соответствующие одноименным событиям системы. Позволяют выполнить инициализацию модулей. | Сервер |
| ПередНачаломРаботыСистемы | Клиент | |
| ПриНачалеРаботыСистемы | Клиент | |
| ФормаПриСозданииНаСервере | Вызывается в форме при создании ее на сервере. В параметр передается ссылка на форму. Форму можно идентифицировать по имени Форма.ИмяФормы. | Сервер |
| ФормаПриОткрытии | Вызывается при открытии формы. В параметры передается ссылка на форму. Форму можно идентифицировать по имени Форма.ИмяФормы. | Клиент |
При вызове события происходит поиск модулей, реализующих заданный интерфейс, и вызов последовательно каждого модуля. Например, можно добиться следующим образом, что событие ПриОткрытии формы будет транслироваться всем модулям, реализующим интерфейс ФормаПриОткрытии:
Для каждого Модуль из МодульноеПриложение.НайтиМодулиПоИнтерфейсу("ФормаПриОткрытии") цикл
ОбщийМодуль = Вычислить(Модуль.ОбработчикКлиент);
ОбщийМодуль.ФормаПриОткрытии(Форма, Отказ);
КонецЦикла;
Модуль же будет в своем общем клиентском модуле содержать определение:
Процедура ФормаПриОткрытии(Форма, Отказ) Экспорт
Если Форма.ИмяФормы = "Справочник.ФизическиеЛица.Форма.ФормаСписка" Тогда
...
КонецЕсли;
КонецПроцедуры
Планируется, что через глобальную подписку на события формы можно будет изменять форму из любого подписавшегося модуля. Пока это предположение, так как есть некоторые непонятные технологические моменты, связанные с указанием обработчиков для команд и элементов управления формы.
Инициализация модулей
Инициализация модулей сейчас проходит при реализации ими интерфейсов:
УстановкаПараметровСеанса()
ПередНачаломРаботыСистемы()
ПриНачалеРаботыСистемы()
Для этого в модуле должны быть определены процедуры:
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры) Экспорт
Процедура ПередНачаломРаботыСистемы(Отказ) Экспорт
Процедура ПриНачалеРаботыСистемы() Экспорт
В этот момент модули могут проверить свои версии и доступные обновления, прочитать настройки и установить параметры пользователя.
Взаимодействие между слабо связанными компонентами
При создании большого и сложного приложения обычным подходом является разделение функциональности по модулям. Желательно минимизировать число статических ссылок между ними. Благодаря этому можно будет независимо разрабатывать, тестировать , развертывать и обновлять компоненты.
Стандартная подписка на события от 1С позволяет компонентам подписаться на события менеджеров и модулей объектов. При этом можно указать, как конкретные объекты, так и группу объектов в целом, например, ДокументОбъект.
Предложенный в статье механизм определения интерфейсов при поиске модулей позволяет реализовать альтернативную подписку на события, не реализованные в стандартных подписках на события от 1С. Например, можно обеспечить вызов таких событий в каждой форме или обработчике элемента управления.
Если нет желания, чтобы модули связывались между собой непосредственно, можно сделать так, чтобы они связывались косвенно через совместно используемый ресурс, такой как регистр или журнал документов. При таком подходе один модуль записывает данные, другой — считывает их.
Составные интерфейсы пользователя
Модульные приложения часто должны предоставлять цельный интерфейс для пользователя, когда один модуль отвечает за одну часть элементов управления, а другой модуль — за другую часть.
Интерфейсная часть модульного подхода применительно к 1С усиленно не прорабатывалась на практике, есть только некоторые мысли на этот счет.
Подписка одного модуля на события создания и открытия формы из другого модуля через реализацию интерфейса ФормаПриСозданииНаСервере и ФормаПриОткрытии может позволить внедрить элементы формы динамически. Для обратной связи можно реализовать интерфейсы, реагирующие на закрытие формы. Хорошо бы было, если бы появился механизм копирования элементов из одной формы в другую. Но при этом необходимо решать проблему переноса обработчиков элементов. Похожий механизм был реализован для неуправляемых форм, например, здесь: http://kb.mista.ru/article.php?id=165
Интересным является обработчик переопределения открытия форм ОбработкаПолученияФорм в менеджере объекта . В случае, если есть главный и зависимый модуль, зависимый модуль может реализовать свою новую форму, включающую функциональность главного модуля и свой. Затем через ОбработкаПолученияФорм подменить своей формой форму главного модуля. Например, есть модуль продажи и зависимый от него модуль резервирования. Модуль продажи содержит свою форму документа реализации, которая показывается, если не подключен модуль резервирования. Как только в системе появляется модуль резервирования, он может переопределить форму продажи, дополнив ее своими реквизитами. При таком подходе модуль продаж может даже не догадываться о существовании модуля резервирования.
//
<div><img src=»//mc.yandex.ru/watch/21031318″ style=»position:absolute; left:-9999px;» alt=»» /></div>
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
С программным созданием элементов все ясно и понятно. Но вопрос в следующем — Как назначить программно созданной кнопке глобальную команду? Не так давно разбирался с данным вопросом и не нашел ответа (м.б. с выходом 8.3.3 что то поменялось?). Если ответ на данный вопрос все еще остается «никак», тогда каким образом будут реализовываться вызовы команд одного модуля из формы, скомпилированной для 2х модулей?
Переосмысление монолита 1С? Очень хорошо. Посмотрите на там уже давно модульная система. Для конкуренции на западе надо делать на удобнее…
Приведите пожалуйста сравнение вашего подхода с подходом БСП (и платформы).
Из сравнение должно стать понятно:
— Какие есть минусы в БСП, которые нельзя обойти локально (требуется придумывать новый подход)
— Какие реальные задачи предлагаемый подход решает радикально лучше, чем подход БСП (платформы)
— У нового подхода нет явных минусов (т.е. нет задач которые бы он решал значительно хуже чем БСП)
Кажется, что такая сравнительная табличка:
— Поможет оценить полезность подхода в целом
— Позволит выделить ключевые механизмы нового подхода
(3) Begemoth80,
поясните, пожалуйста, что вы понимаете под термином (или где/в чем вы увидели) «подход БСП»
бубуд ли на основе данного подхода в результате вашей работы/проекта — какая-нибудь простая, но функциональная ПРИКЛАДНАЯ ДЕМОКОНФА (например, простой торговый учет остатки+резервы, с возможностью отдельного подключения/отключения модулей — особенно интересно посмотреть как это будет сделано при возможно более меклом количестве статических связей между модулями…)
(4) tango,
Подход БСП описан, например, в статье на ИТС «Разработка конфигураций с повторным использованием общего кода и объектов метаданных»
Возможно автор говоря
имеет в виду что-то другое, тогда он напишет об этом явно
Архив базы с примерами из статьи: Module-application.dt (47,77 kb)- ссылка не работает
(1) pahich,
Как я себе это представляю. Это обходной путь до лучших времен, когда 1С станет поддерживать подписку на события из глобальных модулей. Я не знаю о такой поддержке в 8.3.3.
На форме, поддерживающей модульность всегда определен метод в виде:
Ядро несет функциональность (ищет все модули, реализующие интерфейс обработки команд «ФормаОбщаяКоманда»):
Модуль ПриОткрытии формы делает инъекцию — создает команду со ссылкой на обработчик ОбщаяКоманда
Кмд = Форма.Команды.Добавить(«Команда1»);
Кмд.Действие = «НажатиеКнопки»;
Кмд.Заголовок = «Нажатие кнопки»;
Метод модуля ФормаОбщаяКоманда анализирует форму и команду и делает необходимый вызов.
Второй способ — подмена формы, скомпилированной для 2х модулей через ОбработкаПолученияФорм
Подход интересный, но вижу проблему связи модулей разных разработчиков. Например: Модуль «реализация» разработан фирмой А, модуль «резервирование» есть у разработчиков Б и С. В документе реализация товаров от разработчика А есть кнопка «кнопка1», модули резервирование от других производителей разумеется не догадываются о этой кнопке, но их функционалом надо изменить форму поступления товаров, и тоже добавить «кнопка1», угадайте что будет? А если у меня в модуле А есть небольшой функционал резервирования и мне его надо отключить, потому что я буду внедрять расширенный модуль от разработчика Б или С…? а если мне надо часть функционала от Б а часть от С ? как это все совместить… ?
С регистрами еще сложнее насколько я понимаю.. откуда разработчик модуля Б будет знать что модуль А использует регистр «ОстаткиТоваров» а не «ОстаткиНаСкладах» и тд…
(9) AllexSoft, как вариант можно установить правила разработки, и требовать от сторонних разработчиков их соблюдения.
Например:
1. У каждого модуля должна быть определена категория — независимый он или зависимый. Если зависимый, то от каких модулей;
2. Каждый модуль должен вести себя одинаково прилично в двух ситуациях:
— когда в конфигурации только он один (+ модули, без которых он не может) — это проверка самодостаточности;
— когда в конфигурации включены все аттестованные на данный момент модули — это проверка неконфликтности;
3. Отдельно стоит убедиться, что при включении нашего модуля остальные ведут себя прилично — проверка на privacy;
После прохождения проверок модуль можно выделять в отдельную поставку. Или просто выгружать новыми фишками платформы 8.3.
Большую часть этих проверок можно автоматизировать, опять же с помощью новых возможностей платформы (тестируемое приложение).
(9) AllexSoft, также помним, что будет ЭКОСИСТЕМА.
Там же, вероятно, будет форум или другое средство коммуникации между разработчиками.
Ну и варианты:
1. «Эй, пацаны, из какого регистра у вас можно взять остатки оперативные в количественном выражении?»;
2. «Кто делал модуль «Планирование работы сотрудников»? Вы нахера мой справочник «Сотрудники» заюзали, он не для этого»;
3. «Уважаемая администрация, убейте этих лосей, они за каким-то хером в моем регистре итоги пересчитывают каждый день».
(6) Begemoth80, БСП как бы описан, да
нет — описания подхода БСП
**
если кто-то таки этот подход увидит, следуют ли разработчики БСП предполагаемой декларации?
Как все сложно то.
>> Рекурсивно анализируются все подсистемы.
Определить процедуру, в которую добавляются доступные модули
СписокПодсистем = Новый Массив;
СписокПодсистем.Добавить(«Я самая крутая подсистема»);
>> Серверный модуль должен содержать функцию ПолучитьИнтерфейсы(), которая вернет массив строк — поддерживаемые модулем интерфейсы.
Зачем программно получать поддерживаемые интерфейсы, приведи пример.
>> в название нужно добавить префикс или постфикс, отличающих его от аналогичных.
Зачем предлагать решение, которое не решает проблему?
«Горе от ума» (с) Грибоедов.
напоминает: легче свою книжку написать чем прочитать уже написанное…
сколько можно изобретать велосипед
(10), (11) zaebunga, ты веришь в это?) если даже в 1С совместимо продуктах зачастую нет второй конфигурации поставщика, тоесть никто не пользуется тем что есть в платформе, думаешь будет кто то пользоваться рекомендациями от БИТ ? ) оочень сомневаюсь. Да и вспомни качество кода написаное другими разработчиками, часто видел код написанный на коленке?) все еще думаешь что будут пользоваться рекомендациями от БИТа ?
(15) Gilev.Vyacheslav, пока 1С не предложит механизм модульности на уровне платформы это все так и останется поделками
(16) AllexSoft, верю конечно.
Ничего особо сложного нет в том, чтобы разрулить разработчиков. И не таких окучивали, все в начале говорят «это невозможно!» 🙂
С отраслевыми не1Сными работал — согласен, говно обычно. Потому что цели не было сделать круто. Так, чтобы пацанам было не стыдно показать 🙂
ну в принципе как стартап пойдет, но неудобств в плане разработки все равно много
2 Gilev.Vyacheslav — согласен
(15) Gilev.Vyacheslav,
Вячеслав, мы не знакомы с какими-либо материалами, описывающими попытки сделать модульные решения или описывающими неразрешимые проблемы. Если Вам они известны, можете привести ссылку?
(18) zaebunga, со стороны доминиканцев будет сделано максимально красиво, в это можно поверить, но разработчики модулей будут не БИТ, а ребята из франей которым платят за часы и чтобы как то работало на тестовом примерчике. В реале это будет все то же говно, потому что никто за красивость кода и соблюдение стандартов платить никогда не будет.
(8) вот еще вопрос, какая то система лицензирования модулей разрабатывается? какая то система защиты от копирования может будет? я думаю модули платные то будут восновном
(21) AllexSoft, если парни из франей не будут следовать правилам — их «модули» останутся жить на их компьютерах, и они не заработают денег в экосистеме. Нахера они там со своим говном.
До сих пор не было таких правил нигде. В 1С:Совместимо тесты формальные, типа «длина кода строки 80 символов» или «у всех элементов должно быть заполнено пояснение». Ну и отсюда решения соответствующие. Какие правила, такие и решения 🙂
Экосистема, в т.ч. и вендор, не должна позволять клеить свой ярлык «одобряю» на говно.
(22) zaebunga, дай бог если все так будет радужно, а не как обычно у нас в стране ) и всетаки мой мнение: рыба гниет с головы, и пока 1С не пересмотрит подходы к 1С Совместимо в том числе и стандартам разработки все останется как есть, слишком сильно мы зависим от платформы и от компании 1С.
ПС: парням работающим не по правилам ничего не стоит прилепить свой модуль и без разрешения БИТа, но не факт потом что БИТовские модули будут работать.. а виноват кто будет? бит!
(24) AllexSoft, от мудацких доработок на месте никуда не деться. Если клиент допустил к своему экземпляру системы долбо*бов, это его личное дело, согласитесь.
Важно, что свой говенный модуль долбо*бы клиенту напрямую будут ставить, а не сам клиент его через экосистему купит.
Ну я так себе это представляю. Цербер должен на входе в экосистему стоять. Типа серьезный фейсконтроль. Кто уперся лбом, сконцентрировался и фейсконтроль прошел — получает вечное наслаждение, пышногрудых дев и бесконечный поток денег — он в СИСТЕМЕ 🙂 Внутри экосистемы церберов уже нет.
Серьезных отличий от методологии из БСП 2.1 не заметил. Разве что навороты с иерархией подсистем — логика «зачем» мне ясна, но подход не нравится нагруженностью.
(25) zaebunga, я с вами согласен, а что будет если модуль прошел жесткий контроль, его впустили в экосистему, разумеется поставщих начнет делать плюшки к нему, обновлять, а если это будет делать человек-говнокод ? так можно и нормальный модуль запароть. Каждый раз цербера ставить на обновление модуля? У БИТа сил не хватит ковырять чужой код и проверять его на совместимость с системой и остальными модулями. ПС: Вот еще сходу один вопрос про обновление модуле, как, несколько поставщиков опять же ?)
(3) Begemoth80,
Из сравнение должно стать понятно:
— Какие есть минусы в БСП, которые нельзя обойти локально (требуется придумывать новый подход)
— Какие реальные задачи предлагаемый подход решает радикально лучше, чем подход БСП (платформы)
— У нового подхода нет явных минусов (т.е. нет задач которые бы он решал значительно хуже чем БСП)
Кажется, что такая сравнительная табличка:
— Поможет оценить полезность подхода в целом
— Позволит выделить ключевые механизмы нового подхода
Идеи немного различаются. БСП предлагает вобрать в себя всю чаще всего используемую функциональность и оформить ее в виде библиотеки. Эту библиотеку можно встраивать в готовые конфигурации или основывать на ней новые конфигурации. Конфигурации на основе БСП всем известны УТ, УНФ, Документооборот — это монолитные системы, где подсистемы-модули тесно связаны между собой.
Модульный подход, предложенный в статье, задается вопросом — можно ли разделить конфигурацию 1С на множество модулей и обеспечить слабую связь между ними. Это нужно для того, чтобы сторонние разработчики могли независимо писать и предлагать свои модули. Слабая связь между модулями позволит вести более легкую независимую поддержку модулей различных авторов. Обновления одних модулей с меньшей вероятностью вызовут конфликт с модулями других разработчиков. Модульность позволит навести порядок в системе, а в далеком будущем организовать магазин приложений, в т.ч. в облаке по подписке.
Имеет смысл оценивать разные идеи: идею повторного использования кода (БСП) против пакетирования (статья)? Если имеет, то давайте выработаем совместно критерии для оценки — по каким параметрам будем оценивать.
Навскидку:
Уникальность имен: БСП не обеспечивает уникальность имен для своих объектов, что приводи к проблемам, например, таким: Цитирую: «в «1С» решили, что «БСП – это основа» и поэтому ей не нужны префиксы … Ведь это же «библиотека».»
В посте предлагается выработать заранее соглашение на этот счет.
(12) tango,
см. на ИТС в стандартах разработки раздел «Разработка и использование библиотек»
Собственно в нем и содержится статья, ссылку на которую я давал ранее
Этот подход можно увидеть в типовых конфигурациях, которые «стоят на поддержке» у БСП
(5) CheBurator,
Демоверсии, к сожалению, не планируется. Ограниченное время не позволяет. Встала задача организовать комфортное существование наших и сторонних модулей внутри одной будущей системы. Принцип, предполагается, взять как описано в статье. Сейчас важно собрать критику, отзывы и пожелания, чтобы не заложить ошибку в фундамент.
Какую пользу это даст сообществу: будущая система, планируется, будет состоять из множества модулей. Разработчикам с Инфостарта будет интересно заниматься написанием дополнительных модулей или доработкой существующих. Может быть откроется магазин приложений.
(7) ssn5810,
Ресурс Инфостарт не приветствует, как оказалось, хранение файлов на сторонних ресурсах. Архив базы можно скачать из файлов в публикации. Сейчас сломанную ссылку не могу убрать, так как это сделает статью неактивной в течение неопределенного времени из-за премодерации.
(9) AllexSoft,
Можно добавлять не Кнопка1, а Кнопка1_резервирование_Б и Кнопка1_резервирование_С. Это позволит избежать конфликтов. Вы имели ввиду проблему с конфликтом имен?
Думаю, что А и его резервирование пусть остается на его совести. Модуль Б и С будут нести в себе регистры по резервированию и локально внутри себя обрабатывать расширенное резервирование. В зависимости от ситуации можно еще подписаться на события А при проведении и подменить его записи регистров.
Можно сделать модуль Д, в котором дергать функционал Б или С в зависимости от условий.
Если модуль Б пишется как дополнение к А, то модуль Б постарается узнать об А как можно больше. Это А может не знать о существовании модуля Б.
(28) БСП не монолитная библиотека. Часть ее подсистем может внедряться отдельно.
(33) Для внедрения подсистемы БСП необходима работа программиста. Наша задача, чтобы при покупке нового модуля, автоматически делалась поставка, на которую клиент мог бы обновиться, не тратя на это обновление времени специалистов (в случае, если клиент работает в модели SaaS — даже не выгоняя из базы пользователей). По принципам и механизмам поставки отдельных модулей в данный момент готовится статья.
(13) MSensey,
Я сам за простоту.
Определить процедуру, в которую добавляются доступные модули
СписокПодсистем = Новый Массив;
СписокПодсистем.Добавить(«Я самая крутая подсистема»);
Кто будет ответственным за поддержание этой процедуры в актуальном состоянии? Наличие такой процедуры — это появление жестких связей ядра со всеми модулями в системе. А принцип модульности предполагает ослабление связей.
Зачем программно получать поддерживаемые интерфейсы, приведи пример.
Для фильтра, чтобы в нужный момент опрашивать не все подряд модули в цикле через попытка-исключение, а только те, которые поддерживают требуемую функциональность. Пример в ответе (8) для интерфейса ФормаОбщаяКоманда. Будут перебираться не все модули, а только поддерживающие подписку на события команд в формах.
Зачем предлагать решение, которое не решает проблему?
Проблема уникальности названий от разных разработчиков в рамках одной конфигурации решается. Или вы имеете ввиду какую-то другую проблему?
(30) ну и зря… рожать идеи и инструименты — это хорошо.. ровно до тех пор пока этим инструиментом не начать строгать предмет.. тут и выяснится — ручка не с той стороны.. заточка лезвия не под тем углом…
(34) Наша задача, чтобы при покупке нового модуля, автоматически делалась поставка
Об этом в публикации ничего не написано.
Но сама задача отказа от специалиста кажется надуманной.
Реализовать крупную систему, наращивая слабо связанные модули невозможно.
Например, упомянутое резервирование, не сделать на принципах модульности. Оно зависит от того как организован учет товаров, учет товаров зависит от НСИ товаров.
В большинстве случаев отказаться от специалиста по внедрению не получится.
Специалист должен проанализировать возможность встраивания нового модуля.
В модели SaaS клиент покупает модули у поставщика SaaS.
Поставщик SaaS покупает модули у разработчиков, но он не сможет обойтись без того кто встроит эти модули.
(35) Кто будет ответственным за поддержание этой процедуры в актуальном состоянии?
Учитывая, что я написал выше, этим будет заниматься тот кто наращивает используемую систему.
Проблема уникальности названий от разных разработчиков в рамках одной конфигурации решается.
Не решается т.к. разные разработчики модулей могут дать одинаковые префиксы.
(37) Реализовать крупную систему, наращивая слабо связанные модули невозможно.
Здесь я имею ввиду следующее.
Значительную часть системы составляют модули, которые сильно взаимодействуют друг с другом.
Их можно реализовать как модули, но они будут совместимы только с модулями того же разработчика.
Модули разных разработчиков в большинстве случаев не будут взаимодействовать, либо будут слабо взаимодействовать, да и то с заранее определенными модулями.
(2) sikuda, картинки красивые, как будто бы «модульные» 🙂
а что внутри? обычная база данных и никакой модульности? 😉
(38) MSensey В любом случае, уйти от многообразия и вариативности мира не получится.
Разумеется, что возможно на ограниченном временном этапе сделать силами сторонних разработчиков модули достаточно совместимые…
Модульная разработка — практикуется очень давно. Думается и дальше будет процветать объектная модель разработки. Не вижу радикального отличия от данного принципа.
Предполагаю, что рынок разработки модулей, как дополнительных подсистем будет развиваться. Естественным требованием станет описание «внешних интерфейсных объектов, функций» и т.п. Модули будет собирать Программист-Компоновщик. Именно он будет нести ответственность за взаимодействие используемых модулей. Не думаю, что конечный пользователь сможет самостоятельно приклеивать к собственной системе сторонние модули (только, если модуль совсем автономный)…
(0) кол-во взаимоувязок делает идею сложновоспринимаемой. «только для энтузиастов» 🙂
(22) не согласен, (21) согласен
я думаю если ребята будут делиться кейсами своих «модулей», то получится хорошая база модулей. я например много разных разработок с Инфостарта уже использовал как готовые модули, за качество которое отвечает сообщество 🙂
(29) текст и информация реально сложно воспринимается, темы статей — не актуальные: РЛС, переопределяемые модули, совместимости библиотек — далеко от жизни клиентов.
да уж, сделайте жизнь 1С-ника легче пож-та: растолкуйте простыми словами 🙂
(38),
На данный момент мы разрабатываем менее «связанный» модуль — CRM, нежели продажи, заказы и резервирование. На примере его реализации посмотрим насколько реально все остальное. Скорее всего, в результате, деление на модули пойдет от того, что получится разделить функционально (это личное мнение). Также модули реализующие дублирующий функционал типовых решений 1С на данный момент не рассматриваются.
(23) AllexSoft,
Сейчас не ставим такой задачи. Предполагается, что модули будут в основном использоваться в облаке, к которому доступ на уровне кода будет ограничен. Можно со временем продумать совместно какие-то механизмы, например, подписывание. Выгоднее, конечно, работать с платными модулями.
(15) Gilev.Vyacheslav,
Как говорится: «Не боги горшки обжигают». БСП тоже когда-то была «велосипедом». Со временем стала веломобилем.
(33) MSensey,
Особенно странной в этой связи выглядит статья:
Ну и конфигурациям УТ, УНФ, основанным на БСП, ее «немонолитность» не слишком помогла. Они как были монолитными в 8.0, так и остались в 8.3.
У БСП однозначно есть, чем гордиться. Большинство модулей мы разрабатываем с оглядкой на БСП, как своего рода стандарт. Но под наши задачи, к сожалению, она в полном объеме не подходит.
(36) CheBurator,
Лично я полностью согласен с Вами, но нужно выбирать: выделить ресурсы на демоверсию или продвинуться в рамках поставленных задач. Пока что расклад не в пользу демоверсии.
На первый взгляд, очередной велосипед
С другой стороны, в 1с давно не хватает модульности, и как вариант решения пойдет
(0)
«Так, например, у разных поставщиков может быть справочник Настройки. Невозможно добавить справочники с одинаковыми наименованиями в одну конфигурацию. Поэтому в название нужно добавить префикс или постфикс, отличающих его от аналогичных.»(с)
А мне казалось, что должен появиться общий модуль НАСТРОЙКА, а не префикс/постфикс к наименованию. Или общий справочник/таблица единой структуры для всех «модулей». Аналогично и для остальных случаев со «справочником» (условное название). И, думаю, пока не будет вынесено из «конфигурации» описание схемы базы данных (общей для всех «поставщиков» модулей) — никакой модульности системы быть не может.
(51) hogik,
А мне казалось, что должен появиться общий модуль НАСТРОЙКА, а не префикс/постфикс к наименованию. Или общий справочник/таблица единой структуры для всех «модулей». Аналогично и для остальных случаев со «справочником» (условное название). И, думаю, пока не будет вынесено из «конфигурации» описание схемы базы данных (общей для всех «поставщиков» модулей) — никакой модульности системы быть не может.
Подход не запрещает кому-то выпустить свой модуль НастройкиМодулей_вендор, а остальные будут использовать этот модуль для хранения своих настроек. Лучше, если модулей настроек появится несколько от разных разработчиков и самый удобный из них победит в конкурентной борьбе. Далее при определенных обстоятельствах этот модуль можно включить в ядро.
Модульность — это прежде всего конкуренция между разработчиками за использование именно его модуля, а конкуренция ведет к развитию.
(52) по поводу регистров… а вдруг модуль Б запишет некорректные данные для модуля А ? ну для Б они будут корректными, но модуль А не знает о его существовании… разумеется модулей А будет несколько разных от разных вендоров, так что модулю Б который привязан к ним логически под всех уметь подстраиваться? откуда знает Б что модуль А будет от БИТа, а не от РАРУСа ?) а ведь логика работы с регистрами в разных модулях можеть очень серьезно различаться… как выше написали пока данные хранятся в одной бд, да еще и связано тесно (ссылочно) то о модульности говорить рано.. мое ИМХО.
ПС: Если модули будут подстраиваться под конкретных вендоров других модулей и совместно используемых ресурсов данных ни о какой модульности речи быть не может, это получится тоже самое что сейчас, конфигурации на базе типовых. а у вас будет конфигурация на базе модулей А Б С и тд … от БИТА
(52) пс: вопрос не в тему, у вас серая зп? в бите у всех серая, вот мне буквально вчера опять в БИТ предлогали )
когда я писал свою (а вышла она на 15 дней раньше сабжа) я разумеется продумывал описаную у Вас в статье реализацию, это была самая простая идея, заметим что как и мои предложения базой является обьект «подсистема».
Я сразу отказался от идеи построения модульной системы, или любой другой (например объектной) на текущей реализации платформы, главная причина очень простая — будет немерянное количество общих модулей и читабельность просто умрет.
По этому первостепенным считаю встраивание в подсистему модуля менеджера, или как вариант сделать общие модули в виде подчиненного дерева. Без этого вообще говорить не о чем.
Предположим это 1с реализовало, что дальше?
правильно в статье описано что второй проблеммой будет глубокая связь обьектов друг с другом, по этому я предложил в статье реализовать модули двух видов
1. Библиотека подсистем, расширение языка (тут не будет сильных связей, тут будут только стабильные расширяющие процедуры, типа пересчета валюты)
2. Библиотеки прикладных подсистем — это уже конкретные модули реализующие бизнес процессы
жаль, что я не с Вами, идей и статей у меня вагон :)))
Неужели опыт БСП ничему не научил?
1С с БСП видимо подшутили над разработчниками — когда можно 5 раз нажать F12 и попасть в пустую процедуру.
Модульность это «кул» но читая код БСП прямо видится фраза «ЗДЕСЬ ДОЛЖНО БЫТЬ ООП», вот это — «АБСТРАКТНЫЙ КЛАСС», а это «ПЕРЕГРУЗКА МЕТОДА», вот тут у нас «ПОЛИМОРФИЗМ». Тогда можно говорить о модульности… Либо по пути SAP пойти и делать кучу Web сервисов, только вот в 1С нет своей шины, а использовать готовую от IBM (к примеру)… ну не знаю….
(53) AllexSoft,
По-хорошему модуль Б должен нести в себе свой набор регистров и не лезть к А. Если ему нужны данные из модуля А, то получать их запросами или записывать к себе в регистры через подписку на события при проведении документов.
Сложно предсказать, что будет в будущем. Это больше организационный вопрос.
(54) AllexSoft,
К сожалению, я не работаю в БИТе, поэтому не знаю какая у них зарплата
(58) хм.. а на каких условиях вы там работаете (если не секрет) ? доминикана = бит же… или вас там (на доминикане) не трудоустраивали ?
(59) AllexSoft,
Думаю, это не предмет всеобщего обсуждения, тем более в этой теме. Условия средние. Более важно, что люди и задачи интересные, специалисты из разных городов, не только из Москвы. Команда сложилась гармонично, это значит, что после проекта останутся друзья. Еще экзотика.
Модульность обеспечивается жесткими регламентами относительно интерфейсов/построения модулей. Крепкими паттернами проектирования от пользовательского интерфейса до деталей проведения, за отклонение от которых расстрел.
А в топике художественная самодеятельность и штаны на лямках.
А в топике художественная самодеятельность и штаны на лямках.
Вы считаете, что кто-нибудь на данном этапе способен сформулировать жесткие требования? Вам известны конфигурации, построенные на принципе модульности, чтобы подсмотреть там паттерны?
(62) а почему было бы не организовать передачу данных между модулями через Web-сервисы и XDTO ? помоему универсальнее было бы чем через интерфейсы менеджеров подсистем. Тогда бы много проблем решалось с корректностью данных в общих регистрах, ведь был бы один общий интерфейс читающий и записывающий данные в регистр, а модули расширения которые идут к головному модулю обращались бы к данным через веб сервисы головного модуля. Можно было бы написать стандарты ответов веб сервисов и стандарты интерфейсов, кстати это бы упростило и получение данных из внешних источников которые работают с SOAP. Получалась бы гораздо более широкая модульность чем сугубо в рамках платформы (и даже одной конфигурации) 1С
(63) AllexSoft,
Текущий подход не запрещает сделать такой обмен между модулями сторонним вендорам. Если такой способ будет удобным, все его смогут взять на вооружение. Мы планируем пока организовать шину данных для обмена между одноименными модулями, расположенными в SaaS и интегрированными локально к пользователю.
Модули это хорошо.
(48) это статья каких времен? За это время БСП изменилась кардинально, в плане «модульности» внедрения.
(66) Sol, современная БСП префиксы добавляет своим объектам?
(62) не стоит слепо игнорировать регламенты, доминирование, унижение и телесные наказания. WalterMort прав: модульность можно обеспечить правилами. Просто никто не пробовал.
Тут все будет зависеть от владельцев экосистемы.
(2)(40)
Понятие модуль — растяжимое. 😉
Думаю, автору публикации имеет смысл дать своё определение этому понятию.
P.S.
«Создание модуля с нуля за 5 минут»
«Создание меню в OpenERP 6.1»
(68) zaebunga,
Тут все будет зависеть от владельцев экосистемы.
Не было стремления игнорировать их. Я пытался донести мысль, что пока не появится штук 20 модулей от разных производителей, сложно сформулировать требования, а тем более жесткие требования.
(70) ничего страшного в этом нет — можно написать те правила, которые известны на данный момент. И добавить в конце пункт — «Владелец Экосистемы имеет право вносить в правила любые изменения, с уведомлением за 30 дней до начала применения. По истечении 30 дней модули, не прошедшие проверку по новым правилам, будут сливаться в отстойник к херам».
Почему бы не рассматривать разграничение в рамках модульности на уровне интерфейса (универасльного), на подобии использования внешних компонент для 1С, подключений различных плагинов и т.д., соответственно отпадет масса проблем связанных с взаимной интеграцией модулей друг в друга и других вытекающих последствий?
(72) ivanov660,
Внешние компоненты Native API не несут функциональности по интерфейсу. Можно рассмотреть вариант интеграции по html. Например, формирование рабочего стола при загрузке 1С из разных модулей.
По ходу реализации возникла проблема вывода из модулей форм АРМ в рабочую область начальной страницы
Более подробно о проблеме можно почитать в ветке форума.
(0) Модульность — вещь, конечно, интересная, но, на первый взгляд, идея кажется утопичной. Если отследить связи и их корректность между ядром и дополнительным модулем еще представляется возможным, то обеспечить корректное взаимодействие между модулем «А» и модулем «Б» разных разработчиков — очень сложно. А если на это наложить разные версии ядра и модулей, то почти нереально.
Вы говорите, что модульность упростит разработку и поддержку, — это не так. Пусть количество жестких ссылок и уменьшится, но сложность логических связей никуда не исчезнет, а, наоборот, даже возрастёт, так как эти связи нужно будет продумывать более тщательно.
Даже вендор, разрабатывая целостные системы, не использует принцип модульности, и всё из-за того, что такие системы гораздо сложнее разрабатывать, чем «монолиты». На эту тему было несколько лет назад интервью.
При текущем функционале платформы кажутся реальными следующие варианты:
1) Разработать свою целостную модульную систему. Вариант, думаю, выполним, но SaaS и функциональные опции также решают эту проблему, причем, с меньшими затратами.
2) Разработать Ядро и дать возможность разрабатывать к нему дополнительные модули, взаимодействие между ними запретить. Но здесь уже вызывает сомнение востребованность такого решения.
Во всяком случае, желаю вам удачи, задумка у вашего проекта интересная!
Тоже вставлю свои 5 коп. в разговор:
1. Сама идея модульности давно витает в воздухе, но очень сложно реализуема [IMHO].
Сложности во все происходящее добавляет ограниченность платформой 1С. Мне кажется, что все фишки, добавленные в 8-й платформе и её развитии подвели только к идеям энтузиастов о модульности, но реально не дают достаточно инструментов для её реализации. Вот попробуйте сформировать для себя те же цели и задачи не привязываясь к платформе… абстрагируйтесь от платформы и прикиньте какими способами можно было-бы достичь тех же целей. Конечно удобно взять такой инструмент как 1С и не морочиться вопросами хранения данных, организации структуры данных на других уровнях заняться исключительно работой процессов и пр. но есть ограничения которые вынуждают искать обходные варианты решения и они не добавят решению ни сопровождаемости ни скорости.
2. Мне кажется в задаче потребуется добавлять некие модули, которые должны будут отвечать за интеграцию модулей между собой, чтобы в простой и удобной форме все это настраивалось (раз уж проект ориентирован на доступность и удобность системы). И еще, наверное имеет смысл сделать модули атомарнее, менее масштабные по функциональности, но менее зависимые по связям с окружающими (просто мысль). Тогда будет соблюдаться идея Доминиканы про «конструктор LEGO» но есть трудность, как связать разношерстность модулей отвечающих за хранение (запись данных), выборку данных, реализацию интерфейсов и пр.
Да, вот, модули нужно разбить функционально чтобы для каждой функции проработать свои интерфейсы и свои инструменты реализации каких-то общих функций для реализации интегрированности.
И еще архитектурные мысли в догонку:
[IMHO] нужно сделать некое ядро общих модулей с общими интерфейсами, которые будут обеспечивать связи между модулями, проверки наличия нужных модулей, инструменты связи функционала модулей, их взаимодействия и пр.
Спасибо всем за ваши ценные комментарии.
Сейчас в нашей системе несколько модулей: Базовые справочники, Задачи, Управление клиентской базой, База знаний
Разрабатывается центральный для всех модуль Процессная шина.
Эти несколько модулей позволяют сформулировать требования к оформлению модулей. Сейчас известно, что каждый модуль будет сопровождаться функциональной опцией для всех своих элементов. Подсистемы модулей будут помещены в подсистему Модули. Будут интерфейсные подсистемы, расположенные в корне подсистем, чтобы можно было их показывать в панели разделов.
От хранения списка модулей в параметрах сеанса, скорее всего, придется отказаться.
Я полностью поддерживаю идею модульности… мало того, уже 5 лет её активно эксплуатирую и развиваю.
Пришлось выкинуть УТП НА ПОМОЙКУ и начать все с нуля. В системе всего порядка 60 тыс. строк кода, чешутся руки
оставить только 30. Механизмы 1С используются процентов на 5 :))). По функциалу система учетных модулей не уступает УТП.
В плане интерфейса — превосходит на порядок. Проблемы с производительностью отсутствуют как класс.
Как показал опыт создать экосистему из 120 независимых учетных модулей не составляет никакой трудности. Просто модули не должны вызывать друг друга, а использовать общую шину данных и Единые стандартные библиотеки (ЕСБ) примитивных атомарных функций.
В отличие от Библиотеки стандартных подсистем (БСП) глубина вложенности функций ЕСБ не более 2-х.
Для бизнес-приложений достаточно 7-ми базовых регистров.
В основе каждого модуля — лежит основной запрос. Модули полностью конструируется. Обработчики событий подключаются на лету.
Сам модуль — практически не содержит программного кода… Ну разве, что для красоты ))))) можно в событии «после выполнения запроса» разукрасить текст и долепить картинки. Для функционирования модулей используется
набор стандартных библиотек, хранимых в конфигурации, и обновляемые крайне редко.
Сами модули хранятся в базе данных, могут кочевать из одной базы в другую при условии, что базы имеют стандартные библиотеки одной версии.
Модули могут быть легко удалены или инсталированы. Есть проблема — тексты модулей невозможно зашифровать, так как увы, они не содержат функционального кода. Модули легко сохраняюмся в xml штатными средствами 1С.
И могут быть импортированы в любую другую программную среду поддерживающую скрипты. Например PHP+MySQL или VBA+MsSQL.
Есть одно большое НО проектировать «учетные модули» должны не программисты, а прикладные специалисты: управленцы, экономисты и финансисты.Задача программистов — технически обеспечить экосистему взаимодействия «Учетных модулей»
(80) Evgen.Ponomarenko, не хотите написать статью, с примерами и скриншотами ? тут всем было бы интересно увидеть реально функционирующую модульную систему
(80) Evgen.Ponomarenko,
Очень интересно, присоединяюсь к (81) AllexSoft.
(80) Evgen.Ponomarenko,
тоже любопытно взглянуть
(80) Evgen.Ponomarenko,
а кто должен будет объяснить им, чего от них надо-то?
(80) Evgen.Ponomarenko,
А!
(81) AllexSoft,
(80) Evgen.Ponomarenko, не хотите написать статью, с примерами и скриншотами ?
тут всем было бы интересно увидеть реально функционирующую модульную систему
Честно говоря, уже даааавно чешутся руки и статью написать и демо-версию выложить…
Но хочется сделать хорошо, а времени на это пока хватает. Сейчас по неволе работаю спасателем одного
безнадежно убитого проекта. Проект вышел из комы. Состояние клиента — стабильно тяжелое.
В тоже время мне оооочень интересен проект Доминикана, но увы… пока только ночами.
В планах через месяц приступить к разработке CRM-модуля, но перед этим планирую написать статью
на тему «Воронки продаж»
Концепция модульности — очень сложная вещь, что бы её уместить в рамки одной популярной статьи.
Если её писать с нуля — все определения придется давать самостоятельно. Я все таки хочу увидеть структуру модулей
Доминиканы и попробовать пользуясь их терминологией описать свою концепцию.
Система разрабатывалась силами 3-х человек: один идеолог, один разработчик + один специалист технической поддержки.
Когда пришло осознание новизны автор концепции издал книгу «Управление реальным предприятием. Новая концепция.»
автор — Кустов Михаил Геннадиевич.
В книге описана простым языком математика, которая легла в основу прикладного конструктора модулей.
Так, что всему свое время )))) будут и примеры, будут и скриншоты )))))
(85) tango,
Многоуважаемый Михаил, я не понял вашего вопроса — уточните его плиззз.
(86) Evgen.Ponomarenko, ждем с нетерпением
Зачем? В БСП, (особенно в последних версиях — 2.1.5), подход к модульности кажется достаточно глубоко продуманным. Учитывая, что БСП де-факто есть и (или) будет must-have для вновь создаваемых конфигураций, пытаться предложить свой несовместимый (читай, нестандартный) подход, по меньшей мере, недальновидно.
Практически то же самое уже есть в БСП. См. функцию ОписанияПодсистем().
Это вообще никуда не годится — делать фейковую подсистему, которая будет играть роль индикатора того, что это — модуль. Подсистемы преднзначены не для этого. Вы пытаетесь использовать предложенные платформой технологии не по назначению, и предлагаете сделать это стандартом.
Что-то подобное («подписка» модуля на «события» подсистем) уже есть в БСП 2.1.5.
По-моему, это — зло. Интерфейсы должны прорабатываться дизайнером интерфейсов. Если у вас в интерфейсе задействованы несколько «независимых» модулей, то, наверное, лучше стоит сделать несколько продуманных интерфейсов для каждого случая комбинации этих модулей.
Понятно, что модульность снижается, однако, тут уже вопрос приоритетов; о ком вы больше заботитесь: о пользователе или о разработчике.
В продолжение модульности предлагаю обсудить тему сложных интерфейсов с повтоным использованием регионов форм.
И вот тут ррраз, и появляется идеология подсистем в 8.3.6… Кто что думает?
(94) Yashazz,
Сначала не мешает ознакомиться с идеологией. Нет ссылки на представление идеологии от 8.3.6?