gifts2017

Модульные приложения на 1С

Опубликовал Сергей Карташев (Elisy) в раздел Программирование - Практика программирования

Одной из задач Проекта Доминикана было построение приложения, состоящего из множества модулей. Модули нужны в проекте для облегчения поддержки сложного решения и для привлечения сторонних разработчиков с целью продажи их модулей. Данная статья - это попытка выработать подход к построению модульного приложения на платформе 1С.

Модульное приложение

Одной из задач Проекта Доминикана было построение приложения, состоящего из множества модулей. Модули нужны в проекте для облегчения поддержки сложного решения и для привлечения сторонних разработчиков с целью продажи их модулей. Данная статья - это попытка выработать подход к построению модульного приложения на платформе 1С.

Принципы построения модульных приложений на примере .Net framework можно почитать здесь: http://habrahabr.ru/post/176851/

Модульный подход применим для приложений, которые будут активно развиваться во время своей жизни - для приложений, которые построены надолго и для изменений. По другую сторону от модульных приложений стоят монолитные приложения, которые трудно и неэффективно поддерживать. Слово "монолитное" указывает на приложение, в котором компоненты очень тесно связаны, и между ними нет четкого разделения.

Модульный подход позволяет разделить компоненты на слабосвязанные части и поддерживать их разными командами разработчиков. Слабая зависимость позволяет снизить конфликты между независимо добавленным функционалом в разные модули.

Несмотря на то, что 1С выпустила БСП, как шаг к модульности приложений, хотелось бы видеть несколько альтернативных подходов. В некоторых применениях БСП может не подойти.

К статье приложена выгрузка информационной базы с конфигурацией, реализующей несколько модулей и демонстрирующей процесс инициализации модулей. Выгрузка сделана для 1С версии 8.3.3.

Нахождение модулей

В предложенном решении за нахождение модулей отвечает загрузчик, который ищет модули в конфигурации и составляет из них список. Список хранится в параметре сеанса МодулиПриложения. Параметр сеанса позволяет контролировать список доступных модулей, например, в зависимости от прав пользователя или наличия подписки.

Модули в 1С разложены по подсистемам

Принцип нахождения модулей предложен следующий. Рекурсивно анализируются все подсистемы. Если подсистема содержит подсистему МенеджерМодуля, то считается, что данная подсистема - это модуль. Подсистема МенеджерМодуля содержит 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>

Скачать файлы

Наименование Файл Версия Размер
Module-application.dt 25
.dt 47,77Kb
25.06.13
25
.dt 47,77Kb Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Павел Ванин (pahich) 25.06.13 22:30
С программным созданием элементов все ясно и понятно. Но вопрос в следующем - Как назначить программно созданной кнопке глобальную команду? Не так давно разбирался с данным вопросом и не нашел ответа (м.б. с выходом 8.3.3 что то поменялось?). Если ответ на данный вопрос все еще остается "никак", тогда каким образом будут реализовываться вызовы команд одного модуля из формы, скомпилированной для 2х модулей?
2. Сергей Кудашкин (sikuda) 25.06.13 22:58
Переосмысление монолита 1С? Очень хорошо. Посмотрите на openerp.com там уже давно модульная система. Для конкуренции на западе надо делать на удобнее...
3. Valeriy noname (Begemoth80) 25.06.13 23:14
В некоторых применениях БСП может не подойти.

Приведите пожалуйста сравнение вашего подхода с подходом БСП (и платформы).
Из сравнение должно стать понятно:
- Какие есть минусы в БСП, которые нельзя обойти локально (требуется придумывать новый подход)
- Какие реальные задачи предлагаемый подход решает радикально лучше, чем подход БСП (платформы)
- У нового подхода нет явных минусов (т.е. нет задач которые бы он решал значительно хуже чем БСП)

Кажется, что такая сравнительная табличка:
- Поможет оценить полезность подхода в целом
- Позволит выделить ключевые механизмы нового подхода
andukin; Chernik; Makushimo; Elisy; +4 Ответить 2
4. Михаил Ражиков (tango) 26.06.13 00:08
(3) Begemoth80,
Приведите пожалуйста сравнение вашего подхода с подходом БСП
поясните, пожалуйста, что вы понимаете под термином (или где/в чем вы увидели) "подход БСП"
5. Сергей (Che) Коцюра (CheBurator) 26.06.13 04:07
бубуд ли на основе данного подхода в результате вашей работы/проекта - какая-нибудь простая, но функциональная ПРИКЛАДНАЯ ДЕМОКОНФА (например, простой торговый учет остатки+резервы, с возможностью отдельного подключения/отключения модулей - особенно интересно посмотреть как это будет сделано при возможно более меклом количестве статических связей между модулями...)
SeiOkami; SirYozha; +2 Ответить 1
6. Valeriy noname (Begemoth80) 26.06.13 06:22
(4) tango,
Подход БСП описан, например, в статье на ИТС "Разработка конфигураций с повторным использованием общего кода и объектов метаданных" http://www.its.1c.ru/db/v8std#content:2149184200:1

Возможно автор говоря
Несмотря на то, что 1С выпустила БСП, как шаг к модульности приложений, хотелось бы видеть несколько альтернативных подходов. В некоторых применениях БСП может не подойти.

имеет в виду что-то другое, тогда он напишет об этом явно
7. ssn5810 (ssn5810) 26.06.13 07:03
Архив базы с примерами из статьи: Module-application.dt (47,77 kb)- ссылка не работает
8. Сергей Карташев (Elisy) 26.06.13 07:21
(1) pahich,
С программным созданием элементов все ясно и понятно. Но вопрос в следующем - Как назначить программно созданной кнопке глобальную команду? Не так давно разбирался с данным вопросом и не нашел ответа (м.б. с выходом 8.3.3 что то поменялось?). Если ответ на данный вопрос все еще остается "никак", тогда каким образом будут реализовываться вызовы команд одного модуля из формы, скомпилированной для 2х модулей?

Как я себе это представляю. Это обходной путь до лучших времен, когда 1С станет поддерживать подписку на события из глобальных модулей. Я не знаю о такой поддержке в 8.3.3.
На форме, поддерживающей модульность всегда определен метод в виде:
&НаКлиенте
Процедура ОбщаяКоманда(Команда)
    МодульноеПриложениеКлиент.ФормаОбщаяКоманда(ЭтаФорма, Команда);
КонецПроцедуры
...Показать Скрыть

Ядро несет функциональность (ищет все модули, реализующие интерфейс обработки команд "ФормаОбщаяКоманда"):
Процедура ФормаОбщаяКоманда(Форма, Команда) Экспорт
	Для каждого Модуль из МодульноеПриложение_1бит.НайтиМодулиПоИнтерфейсу("ФормаОбщаяКоманда") цикл
		ОбщийМодуль = Вычислить(Модуль.ОбработчикКлиент);
		ОбщийМодуль.ФормаОбщаяКоманда(Форма, Команда);
	КонецЦикла;		
КонецПроцедуры
...Показать Скрыть

Модуль ПриОткрытии формы делает инъекцию - создает команду со ссылкой на обработчик ОбщаяКоманда

Кмд = Форма.Команды.Добавить("Команда1");
Кмд.Действие = "НажатиеКнопки";
Кмд.Заголовок = "Нажатие кнопки";

Метод модуля ФормаОбщаяКоманда анализирует форму и команду и делает необходимый вызов.

Второй способ - подмена формы, скомпилированной для 2х модулей через ОбработкаПолученияФорм
9. Алексей Белоусов (AllexSoft) 26.06.13 09:55
Подход интересный, но вижу проблему связи модулей разных разработчиков. Например: Модуль "реализация" разработан фирмой А, модуль "резервирование" есть у разработчиков Б и С. В документе реализация товаров от разработчика А есть кнопка "кнопка1", модули резервирование от других производителей разумеется не догадываются о этой кнопке, но их функционалом надо изменить форму поступления товаров, и тоже добавить "кнопка1", угадайте что будет? А если у меня в модуле А есть небольшой функционал резервирования и мне его надо отключить, потому что я буду внедрять расширенный модуль от разработчика Б или С...? а если мне надо часть функционала от Б а часть от С ? как это все совместить... ?
С регистрами еще сложнее насколько я понимаю.. откуда разработчик модуля Б будет знать что модуль А использует регистр "ОстаткиТоваров" а не "ОстаткиНаСкладах" и тд...
10. zaebunga (1c-intelligence) 26.06.13 10:27
(9) AllexSoft, как вариант можно установить правила разработки, и требовать от сторонних разработчиков их соблюдения.

Например:
1. У каждого модуля должна быть определена категория - независимый он или зависимый. Если зависимый, то от каких модулей;
2. Каждый модуль должен вести себя одинаково прилично в двух ситуациях:
- когда в конфигурации только он один (+ модули, без которых он не может) - это проверка самодостаточности;
- когда в конфигурации включены все аттестованные на данный момент модули - это проверка неконфликтности;
3. Отдельно стоит убедиться, что при включении нашего модуля остальные ведут себя прилично - проверка на privacy;

После прохождения проверок модуль можно выделять в отдельную поставку. Или просто выгружать новыми фишками платформы 8.3.

Большую часть этих проверок можно автоматизировать, опять же с помощью новых возможностей платформы (тестируемое приложение).
11. zaebunga (1c-intelligence) 26.06.13 10:31
(9) AllexSoft, также помним, что будет ЭКОСИСТЕМА.

Там же, вероятно, будет форум или другое средство коммуникации между разработчиками.

Ну и варианты:
1. "Эй, пацаны, из какого регистра у вас можно взять остатки оперативные в количественном выражении?";
2. "Кто делал модуль "Планирование работы сотрудников"? Вы нахера мой справочник "Сотрудники" заюзали, он не для этого";
3. "Уважаемая администрация, убейте этих лосей, они за каким-то хером в моем регистре итоги пересчитывают каждый день".
12. Михаил Ражиков (tango) 26.06.13 10:56
(6) Begemoth80, БСП как бы описан, да
нет - описания подхода БСП
**
если кто-то таки этот подход увидит, следуют ли разработчики БСП предполагаемой декларации?
13. Sensey Master (MSensey) 26.06.13 11:07
Как все сложно то.

>> Рекурсивно анализируются все подсистемы.
Определить процедуру, в которую добавляются доступные модули
СписокПодсистем = Новый Массив;
СписокПодсистем.Добавить("Я самая крутая подсистема");

>> Серверный модуль должен содержать функцию ПолучитьИнтерфейсы(), которая вернет массив строк - поддерживаемые модулем интерфейсы.
Зачем программно получать поддерживаемые интерфейсы, приведи пример.

>> в название нужно добавить префикс или постфикс, отличающих его от аналогичных.
Зачем предлагать решение, которое не решает проблему?
Rustig; Elisy; +2 Ответить 1
14. bulpi bulpi (bulpi) 26.06.13 11:18
"Горе от ума" (с) Грибоедов.
15. Вячеслав Гилёв (Gilev.Vyacheslav) 26.06.13 11:53
напоминает: легче свою книжку написать чем прочитать уже написанное...

сколько можно изобретать велосипед
ojiojiowka; investec; wolfsoft; zqzq; Chernik; Rustig; lamelioss; +7 Ответить 3
16. Алексей Белоусов (AllexSoft) 26.06.13 11:56
(10), (11) zaebunga, ты веришь в это?) если даже в 1С совместимо продуктах зачастую нет второй конфигурации поставщика, тоесть никто не пользуется тем что есть в платформе, думаешь будет кто то пользоваться рекомендациями от БИТ ? ) оочень сомневаюсь. Да и вспомни качество кода написаное другими разработчиками, часто видел код написанный на коленке?) все еще думаешь что будут пользоваться рекомендациями от БИТа ?
Chernik; Rustig; +2 Ответить 1
17. Алексей Белоусов (AllexSoft) 26.06.13 11:59
(15) Gilev.Vyacheslav, пока 1С не предложит механизм модульности на уровне платформы это все так и останется поделками
18. zaebunga (1c-intelligence) 26.06.13 12:10
(16) AllexSoft, верю конечно.

Ничего особо сложного нет в том, чтобы разрулить разработчиков. И не таких окучивали, все в начале говорят "это невозможно!" :)

С отраслевыми не1Сными работал - согласен, говно обычно. Потому что цели не было сделать круто. Так, чтобы пацанам было не стыдно показать :)
19. Андрей Карев (lamelioss) 26.06.13 12:21
ну в принципе как стартап пойдет, но неудобств в плане разработки все равно много
2 Gilev.Vyacheslav - согласен
20. Александр Давыдов (frying) 26.06.13 12:25
(15) Gilev.Vyacheslav,
Вячеслав, мы не знакомы с какими-либо материалами, описывающими попытки сделать модульные решения или описывающими неразрешимые проблемы. Если Вам они известны, можете привести ссылку?
21. Алексей Белоусов (AllexSoft) 26.06.13 12:27
(18) zaebunga, со стороны доминиканцев будет сделано максимально красиво, в это можно поверить, но разработчики модулей будут не БИТ, а ребята из франей которым платят за часы и чтобы как то работало на тестовом примерчике. В реале это будет все то же говно, потому что никто за красивость кода и соблюдение стандартов платить никогда не будет.
22. zaebunga (1c-intelligence) 26.06.13 12:39
(21) AllexSoft, если парни из франей не будут следовать правилам - их "модули" останутся жить на их компьютерах, и они не заработают денег в экосистеме. Нахера они там со своим говном.

До сих пор не было таких правил нигде. В 1С:Совместимо тесты формальные, типа "длина кода строки 80 символов" или "у всех элементов должно быть заполнено пояснение". Ну и отсюда решения соответствующие. Какие правила, такие и решения :)

Экосистема, в т.ч. и вендор, не должна позволять клеить свой ярлык "одобряю" на говно.
23. Алексей Белоусов (AllexSoft) 26.06.13 12:39
(8) Elisy, вот еще вопрос, какая то система лицензирования модулей разрабатывается? какая то система защиты от копирования может будет? я думаю модули платные то будут восновном
24. Алексей Белоусов (AllexSoft) 26.06.13 12:43
(22) zaebunga, дай бог если все так будет радужно, а не как обычно у нас в стране ) и всетаки мой мнение: рыба гниет с головы, и пока 1С не пересмотрит подходы к 1С Совместимо в том числе и стандартам разработки все останется как есть, слишком сильно мы зависим от платформы и от компании 1С.
ПС: парням работающим не по правилам ничего не стоит прилепить свой модуль и без разрешения БИТа, но не факт потом что БИТовские модули будут работать.. а виноват кто будет? бит!
25. zaebunga (1c-intelligence) 26.06.13 12:51
(24) AllexSoft, от мудацких доработок на месте никуда не деться. Если клиент допустил к своему экземпляру системы долбо*бов, это его личное дело, согласитесь.

Важно, что свой говенный модуль долбо*бы клиенту напрямую будут ставить, а не сам клиент его через экосистему купит.
Ну я так себе это представляю. Цербер должен на входе в экосистему стоять. Типа серьезный фейсконтроль. Кто уперся лбом, сконцентрировался и фейсконтроль прошел - получает вечное наслаждение, пышногрудых дев и бесконечный поток денег - он в СИСТЕМЕ :) Внутри экосистемы церберов уже нет.
26. Сергей Борисов (juntatalor) 26.06.13 13:03
Серьезных отличий от методологии из БСП 2.1 не заметил. Разве что навороты с иерархией подсистем - логика "зачем" мне ясна, но подход не нравится нагруженностью.
27. Алексей Белоусов (AllexSoft) 26.06.13 13:13
(25) zaebunga, я с вами согласен, а что будет если модуль прошел жесткий контроль, его впустили в экосистему, разумеется поставщих начнет делать плюшки к нему, обновлять, а если это будет делать человек-говнокод ? так можно и нормальный модуль запароть. Каждый раз цербера ставить на обновление модуля? У БИТа сил не хватит ковырять чужой код и проверять его на совместимость с системой и остальными модулями. ПС: Вот еще сходу один вопрос про обновление модуле, как, несколько поставщиков опять же ?)
28. Сергей Карташев (Elisy) 26.06.13 13:24
(3) Begemoth80,
Приведите пожалуйста сравнение вашего подхода с подходом БСП (и платформы).
Из сравнение должно стать понятно:
- Какие есть минусы в БСП, которые нельзя обойти локально (требуется придумывать новый подход)
- Какие реальные задачи предлагаемый подход решает радикально лучше, чем подход БСП (платформы)
- У нового подхода нет явных минусов (т.е. нет задач которые бы он решал значительно хуже чем БСП)

Кажется, что такая сравнительная табличка:
- Поможет оценить полезность подхода в целом
- Позволит выделить ключевые механизмы нового подхода


Идеи немного различаются. БСП предлагает вобрать в себя всю чаще всего используемую функциональность и оформить ее в виде библиотеки. Эту библиотеку можно встраивать в готовые конфигурации или основывать на ней новые конфигурации. Конфигурации на основе БСП всем известны УТ, УНФ, Документооборот - это монолитные системы, где подсистемы-модули тесно связаны между собой.
Модульный подход, предложенный в статье, задается вопросом - можно ли разделить конфигурацию 1С на множество модулей и обеспечить слабую связь между ними. Это нужно для того, чтобы сторонние разработчики могли независимо писать и предлагать свои модули. Слабая связь между модулями позволит вести более легкую независимую поддержку модулей различных авторов. Обновления одних модулей с меньшей вероятностью вызовут конфликт с модулями других разработчиков. Модульность позволит навести порядок в системе, а в далеком будущем организовать магазин приложений, в т.ч. в облаке по подписке.
Имеет смысл оценивать разные идеи: идею повторного использования кода (БСП) против пакетирования (статья)? Если имеет, то давайте выработаем совместно критерии для оценки - по каким параметрам будем оценивать.
Навскидку:
Уникальность имен: БСП не обеспечивает уникальность имен для своих объектов, что приводи к проблемам, например, таким: http://infostart.ru/public/121312/ Цитирую: "в «1С» решили, что «БСП – это основа» и поэтому ей не нужны префиксы ... Ведь это же «библиотека»."
В посте предлагается выработать заранее соглашение на этот счет.
29. Valeriy noname (Begemoth80) 26.06.13 13:28
(12) tango,
нет - описания подхода БСП

см. на ИТС в стандартах разработки раздел "Разработка и использование библиотек" http://www.its.1c.ru/db/v8std#browse:13:-1:88
Собственно в нем и содержится статья, ссылку на которую я давал ранее

если кто-то таки этот подход увидит, следуют ли разработчики БСП предполагаемой декларации?

Этот подход можно увидеть в типовых конфигурациях, которые "стоят на поддержке" у БСП
30. Сергей Карташев (Elisy) 26.06.13 13:41
(5) CheBurator,
будут ли на основе данного подхода в результате вашей работы/проекта - какая-нибудь простая, но функциональная ПРИКЛАДНАЯ ДЕМОКОНФА (например, простой торговый учет остатки+резервы, с возможностью отдельного подключения/отключения модулей - особенно интересно посмотреть как это будет сделано при возможно более меклом количестве статических связей между модулями...)

Демоверсии, к сожалению, не планируется. Ограниченное время не позволяет. Встала задача организовать комфортное существование наших и сторонних модулей внутри одной будущей системы. Принцип, предполагается, взять как описано в статье. Сейчас важно собрать критику, отзывы и пожелания, чтобы не заложить ошибку в фундамент.
Какую пользу это даст сообществу: будущая система, планируется, будет состоять из множества модулей. Разработчикам с Инфостарта будет интересно заниматься написанием дополнительных модулей или доработкой существующих. Может быть откроется магазин приложений.
31. Сергей Карташев (Elisy) 26.06.13 14:37
(7) ssn5810,
Архив базы с примерами из статьи: Module-application.dt (47,77 kb)- ссылка не работает

Ресурс Инфостарт не приветствует, как оказалось, хранение файлов на сторонних ресурсах. Архив базы можно скачать из файлов в публикации. Сейчас сломанную ссылку не могу убрать, так как это сделает статью неактивной в течение неопределенного времени из-за премодерации.
32. Сергей Карташев (Elisy) 26.06.13 14:50
(9) AllexSoft,
Подход интересный, но вижу проблему связи модулей разных разработчиков. Например: Модуль "реализация" разработан фирмой А, модуль "резервирование" есть у разработчиков Б и С. В документе реализация товаров от разработчика А есть кнопка "кнопка1", модули резервирование от других производителей разумеется не догадываются о этой кнопке, но их функционалом надо изменить форму поступления товаров, и тоже добавить "кнопка1", угадайте что будет?

Можно добавлять не Кнопка1, а Кнопка1_резервирование_Б и Кнопка1_резервирование_С. Это позволит избежать конфликтов. Вы имели ввиду проблему с конфликтом имен?
А если у меня в модуле А есть небольшой функционал резервирования и мне его надо отключить, потому что я буду внедрять расширенный модуль от разработчика Б или С...?

Думаю, что А и его резервирование пусть остается на его совести. Модуль Б и С будут нести в себе регистры по резервированию и локально внутри себя обрабатывать расширенное резервирование. В зависимости от ситуации можно еще подписаться на события А при проведении и подменить его записи регистров.

а если мне надо часть функционала от Б а часть от С ? как это все совместить... ?

Можно сделать модуль Д, в котором дергать функционал Б или С в зависимости от условий.

С регистрами еще сложнее насколько я понимаю.. откуда разработчик модуля Б будет знать что модуль А использует регистр "ОстаткиТоваров" а не "ОстаткиНаСкладах" и тд...

Если модуль Б пишется как дополнение к А, то модуль Б постарается узнать об А как можно больше. Это А может не знать о существовании модуля Б.
invertercant; +1 Ответить
33. Sensey Master (MSensey) 26.06.13 15:02
(28) БСП не монолитная библиотека. Часть ее подсистем может внедряться отдельно.
34. Ярослав Попов (YOr!k) 26.06.13 15:12
(33) Для внедрения подсистемы БСП необходима работа программиста. Наша задача, чтобы при покупке нового модуля, автоматически делалась поставка, на которую клиент мог бы обновиться, не тратя на это обновление времени специалистов (в случае, если клиент работает в модели SaaS - даже не выгоняя из базы пользователей). По принципам и механизмам поставки отдельных модулей в данный момент готовится статья.
35. Сергей Карташев (Elisy) 26.06.13 15:30
(13) MSensey,
Я сам за простоту.

>> Рекурсивно анализируются все подсистемы.
Определить процедуру, в которую добавляются доступные модули
СписокПодсистем = Новый Массив;
СписокПодсистем.Добавить("Я самая крутая подсистема");

Кто будет ответственным за поддержание этой процедуры в актуальном состоянии? Наличие такой процедуры - это появление жестких связей ядра со всеми модулями в системе. А принцип модульности предполагает ослабление связей.

>> Серверный модуль должен содержать функцию ПолучитьИнтерфейсы(), которая вернет массив строк - поддерживаемые модулем интерфейсы.
Зачем программно получать поддерживаемые интерфейсы, приведи пример.

Для фильтра, чтобы в нужный момент опрашивать не все подряд модули в цикле через попытка-исключение, а только те, которые поддерживают требуемую функциональность. Пример в ответе (8) для интерфейса ФормаОбщаяКоманда. Будут перебираться не все модули, а только поддерживающие подписку на события команд в формах.

>> в название нужно добавить префикс или постфикс, отличающих его от аналогичных.
Зачем предлагать решение, которое не решает проблему?

Проблема уникальности названий от разных разработчиков в рамках одной конфигурации решается. Или вы имеете ввиду какую-то другую проблему?
36. Сергей (Che) Коцюра (CheBurator) 26.06.13 16:21
(30) ну и зря... рожать идеи и инструименты - это хорошо.. ровно до тех пор пока этим инструиментом не начать строгать предмет.. тут и выяснится - ручка не с той стороны.. заточка лезвия не под тем углом...
wolfsoft; zqzq; AllexSoft; Elisy; +4 Ответить 1
37. Sensey Master (MSensey) 26.06.13 16:41
(34) Наша задача, чтобы при покупке нового модуля, автоматически делалась поставка
Об этом в публикации ничего не написано.
Но сама задача отказа от специалиста кажется надуманной.
Реализовать крупную систему, наращивая слабо связанные модули невозможно.
Например, упомянутое резервирование, не сделать на принципах модульности. Оно зависит от того как организован учет товаров, учет товаров зависит от НСИ товаров.
В большинстве случаев отказаться от специалиста по внедрению не получится.
Специалист должен проанализировать возможность встраивания нового модуля.

В модели SaaS клиент покупает модули у поставщика SaaS.
Поставщик SaaS покупает модули у разработчиков, но он не сможет обойтись без того кто встроит эти модули.

(35) Кто будет ответственным за поддержание этой процедуры в актуальном состоянии?
Учитывая, что я написал выше, этим будет заниматься тот кто наращивает используемую систему.

Проблема уникальности названий от разных разработчиков в рамках одной конфигурации решается.
Не решается т.к. разные разработчики модулей могут дать одинаковые префиксы.
38. Sensey Master (MSensey) 26.06.13 17:03
(37) Реализовать крупную систему, наращивая слабо связанные модули невозможно.
Здесь я имею ввиду следующее.
Значительную часть системы составляют модули, которые сильно взаимодействуют друг с другом.
Их можно реализовать как модули, но они будут совместимы только с модулями того же разработчика.
Модули разных разработчиков в большинстве случаев не будут взаимодействовать, либо будут слабо взаимодействовать, да и то с заранее определенными модулями.
39. г. Казань Рустем Гумеров (Rustig) 26.06.13 18:11
(6) сырая статья на ИТС :(
хоть бы постыдились такую ссылку давать ;)
40. г. Казань Рустем Гумеров (Rustig) 26.06.13 18:13
(2) sikuda, картинки красивые, как будто бы "модульные" :)
а что внутри? обычная база данных и никакой модульности? ;)
41. Вадим Никонов (V.Nikonov) 26.06.13 18:16
(38) MSensey В любом случае, уйти от многообразия и вариативности мира не получится.
Разумеется, что возможно на ограниченном временном этапе сделать силами сторонних разработчиков модули достаточно совместимые...
Модульная разработка - практикуется очень давно. Думается и дальше будет процветать объектная модель разработки. Не вижу радикального отличия от данного принципа.
Предполагаю, что рынок разработки модулей, как дополнительных подсистем будет развиваться. Естественным требованием станет описание "внешних интерфейсных объектов, функций" и т.п. Модули будет собирать Программист-Компоновщик. Именно он будет нести ответственность за взаимодействие используемых модулей. Не думаю, что конечный пользователь сможет самостоятельно приклеивать к собственной системе сторонние модули (только, если модуль совсем автономный)...
42. г. Казань Рустем Гумеров (Rustig) 26.06.13 18:18
(0) кол-во взаимоувязок делает идею сложновоспринимаемой. "только для энтузиастов" :)
43. г. Казань Рустем Гумеров (Rustig) 26.06.13 18:22
(22) не согласен, (21) согласен
я думаю если ребята будут делиться кейсами своих "модулей", то получится хорошая база модулей. я например много разных разработок с Инфостарта уже использовал как готовые модули, за качество которое отвечает сообщество :)
44. г. Казань Рустем Гумеров (Rustig) 26.06.13 18:30
(29) текст и информация реально сложно воспринимается, темы статей - не актуальные: РЛС, переопределяемые модули, совместимости библиотек - далеко от жизни клиентов.
да уж, сделайте жизнь 1С-ника легче пож-та: растолкуйте простыми словами :)
45. Александр Давыдов (frying) 26.06.13 18:45
(38),
На данный момент мы разрабатываем менее "связанный" модуль - CRM, нежели продажи, заказы и резервирование. На примере его реализации посмотрим насколько реально все остальное. Скорее всего, в результате, деление на модули пойдет от того, что получится разделить функционально (это личное мнение). Также модули реализующие дублирующий функционал типовых решений 1С на данный момент не рассматриваются.
46. Сергей Карташев (Elisy) 26.06.13 18:46
(23) AllexSoft,
(8) Elisy, вот еще вопрос, какая то система лицензирования модулей разрабатывается? какая то система защиты от копирования может будет? я думаю модули платные то будут восновном

Сейчас не ставим такой задачи. Предполагается, что модули будут в основном использоваться в облаке, к которому доступ на уровне кода будет ограничен. Можно со временем продумать совместно какие-то механизмы, например, подписывание. Выгоднее, конечно, работать с платными модулями.
47. Сергей Карташев (Elisy) 26.06.13 18:52
(15) Gilev.Vyacheslav,
сколько можно изобретать велосипед

Как говорится: "Не боги горшки обжигают". БСП тоже когда-то была "велосипедом". Со временем стала веломобилем.
48. Сергей Карташев (Elisy) 26.06.13 19:04
(33) MSensey,
(28) БСП не монолитная библиотека. Часть ее подсистем может внедряться отдельно.

Особенно странной в этой связи выглядит статья: http://infostart.ru/public/121312/
Ну и конфигурациям УТ, УНФ, основанным на БСП, ее "немонолитность" не слишком помогла. Они как были монолитными в 8.0, так и остались в 8.3.
У БСП однозначно есть, чем гордиться. Большинство модулей мы разрабатываем с оглядкой на БСП, как своего рода стандарт. Но под наши задачи, к сожалению, она в полном объеме не подходит.
49. Сергей Карташев (Elisy) 26.06.13 19:08
(36) CheBurator,
(30) ну и зря... рожать идеи и инструименты - это хорошо.. ровно до тех пор пока этим инструиментом не начать строгать предмет.. тут и выяснится - ручка не с той стороны.. заточка лезвия не под тем углом...

Лично я полностью согласен с Вами, но нужно выбирать: выделить ресурсы на демоверсию или продвинуться в рамках поставленных задач. Пока что расклад не в пользу демоверсии.
50. MV (imm0rtal) 26.06.13 21:24
На первый взгляд, очередной велосипед
С другой стороны, в 1с давно не хватает модульности, и как вариант решения пойдет
51. Владимир (hogik) 26.06.13 22:34
(0)
"Так, например, у разных поставщиков может быть справочник Настройки. Невозможно добавить справочники с одинаковыми наименованиями в одну конфигурацию. Поэтому в название нужно добавить префикс или постфикс, отличающих его от аналогичных."(с)

А мне казалось, что должен появиться общий модуль НАСТРОЙКА, а не префикс/постфикс к наименованию. Или общий справочник/таблица единой структуры для всех "модулей". Аналогично и для остальных случаев со "справочником" (условное название). И, думаю, пока не будет вынесено из "конфигурации" описание схемы базы данных (общей для всех "поставщиков" модулей) - никакой модульности системы быть не может.
52. Сергей Карташев (Elisy) 27.06.13 06:20
(51) hogik,
"Так, например, у разных поставщиков может быть справочник Настройки. Невозможно добавить справочники с одинаковыми наименованиями в одну конфигурацию. Поэтому в название нужно добавить префикс или постфикс, отличающих его от аналогичных."(с)

А мне казалось, что должен появиться общий модуль НАСТРОЙКА, а не префикс/постфикс к наименованию. Или общий справочник/таблица единой структуры для всех "модулей". Аналогично и для остальных случаев со "справочником" (условное название). И, думаю, пока не будет вынесено из "конфигурации" описание схемы базы данных (общей для всех "поставщиков" модулей) - никакой модульности системы быть не может.

Подход не запрещает кому-то выпустить свой модуль НастройкиМодулей_вендор, а остальные будут использовать этот модуль для хранения своих настроек. Лучше, если модулей настроек появится несколько от разных разработчиков и самый удобный из них победит в конкурентной борьбе. Далее при определенных обстоятельствах этот модуль можно включить в ядро.
Модульность - это прежде всего конкуренция между разработчиками за использование именно его модуля, а конкуренция ведет к развитию.
53. Алексей Белоусов (AllexSoft) 27.06.13 08:34
(52) Elisy, по поводу регистров... а вдруг модуль Б запишет некорректные данные для модуля А ? ну для Б они будут корректными, но модуль А не знает о его существовании... разумеется модулей А будет несколько разных от разных вендоров, так что модулю Б который привязан к ним логически под всех уметь подстраиваться? откуда знает Б что модуль А будет от БИТа, а не от РАРУСа ?) а ведь логика работы с регистрами в разных модулях можеть очень серьезно различаться... как выше написали пока данные хранятся в одной бд, да еще и связано тесно (ссылочно) то о модульности говорить рано.. мое ИМХО.
ПС: Если модули будут подстраиваться под конкретных вендоров других модулей и совместно используемых ресурсов данных ни о какой модульности речи быть не может, это получится тоже самое что сейчас, конфигурации на базе типовых. а у вас будет конфигурация на базе модулей А Б С и тд ... от БИТА
54. Алексей Белоусов (AllexSoft) 27.06.13 08:38
(52) Elisy, пс: вопрос не в тему, у вас серая зп? в бите у всех серая, вот мне буквально вчера опять в БИТ предлогали )
55. Дмитрий Воробьев (vde69) 27.06.13 09:04
когда я писал свою статью (а вышла она на 15 дней раньше сабжа) я разумеется продумывал описаную у Вас в статье реализацию, это была самая простая идея, заметим что как и мои предложения базой является обьект "подсистема".

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

По этому первостепенным считаю встраивание в подсистему модуля менеджера, или как вариант сделать общие модули в виде подчиненного дерева. Без этого вообще говорить не о чем.

Предположим это 1с реализовало, что дальше?
правильно в статье описано что второй проблеммой будет глубокая связь обьектов друг с другом, по этому я предложил в статье реализовать модули двух видов
1. Библиотека подсистем, расширение языка (тут не будет сильных связей, тут будут только стабильные расширяющие процедуры, типа пересчета валюты)
2. Библиотеки прикладных подсистем - это уже конкретные модули реализующие бизнес процессы

жаль, что я не с Вами, идей и статей у меня вагон :)))
Ish_2; Elisy; +2 Ответить
56. Олег Филиппов (comol) 27.06.13 10:21
Неужели опыт БСП ничему не научил?
1С с БСП видимо подшутили над разработчниками - когда можно 5 раз нажать F12 и попасть в пустую процедуру.
Модульность это "кул" но читая код БСП прямо видится фраза "ЗДЕСЬ ДОЛЖНО БЫТЬ ООП", вот это - "АБСТРАКТНЫЙ КЛАСС", а это "ПЕРЕГРУЗКА МЕТОДА", вот тут у нас "ПОЛИМОРФИЗМ". Тогда можно говорить о модульности... Либо по пути SAP пойти и делать кучу Web сервисов, только вот в 1С нет своей шины, а использовать готовую от IBM (к примеру)... ну не знаю....
kote; AllexSoft; Ish_2; Georgich88; Elisy; +5 Ответить
57. Сергей Карташев (Elisy) 27.06.13 10:23
(53) AllexSoft,
(52) Elisy, по поводу регистров... а вдруг модуль Б запишет некорректные данные для модуля А ? ну для Б они будут корректными, но модуль А не знает о его существовании... разумеется модулей А будет несколько разных от разных вендоров, так что модулю Б который привязан к ним логически под всех уметь подстраиваться? откуда знает Б что модуль А будет от БИТа, а не от РАРУСа ?) а ведь логика работы с регистрами в разных модулях можеть очень серьезно различаться... как выше написали пока данные хранятся в одной бд, да еще и связано тесно (ссылочно) то о модульности говорить рано.. мое ИМХО.

По-хорошему модуль Б должен нести в себе свой набор регистров и не лезть к А. Если ему нужны данные из модуля А, то получать их запросами или записывать к себе в регистры через подписку на события при проведении документов.
ПС: Если модули будут подстраиваться под конкретных вендоров других модулей и совместно используемых ресурсов данных ни о какой модульности речи быть не может, это получится тоже самое что сейчас, конфигурации на базе типовых. а у вас будет конфигурация на базе модулей А Б С и тд ... от БИТА

Сложно предсказать, что будет в будущем. Это больше организационный вопрос.
58. Сергей Карташев (Elisy) 27.06.13 10:25
(54) AllexSoft,
(52) Elisy, пс: вопрос не в тему, у вас серая зп? в бите у всех серая, вот мне буквально вчера опять в БИТ предлогали )

К сожалению, я не работаю в БИТе, поэтому не знаю какая у них зарплата
59. Алексей Белоусов (AllexSoft) 27.06.13 11:24
(58) Elisy, хм.. а на каких условиях вы там работаете (если не секрет) ? доминикана = бит же... или вас там (на доминикане) не трудоустраивали ?
60. Сергей Карташев (Elisy) 27.06.13 14:22
(59) AllexSoft,
(58) Elisy, хм.. а на каких условиях вы там работаете (если не секрет) ? доминикана = бит же... или вас там (на доминикане) не трудоустраивали ?

Думаю, это не предмет всеобщего обсуждения, тем более в этой теме. Условия средние. Более важно, что люди и задачи интересные, специалисты из разных городов, не только из Москвы. Команда сложилась гармонично, это значит, что после проекта останутся друзья. Еще экзотика.
61. Walter (WalterMort) 27.06.13 14:39
Модульность обеспечивается жесткими регламентами относительно интерфейсов/построения модулей. Крепкими паттернами проектирования от пользовательского интерфейса до деталей проведения, за отклонение от которых расстрел.
А в топике художественная самодеятельность и штаны на лямках.
Chernik; hogik; Elisy; +3 Ответить
62. Сергей Карташев (Elisy) 27.06.13 14:47
Модульность обеспечивается жесткими регламентами относительно интерфейсов/построения модулей. Крепкими паттернами проектирования от пользовательского интерфейса до деталей проведения, за отклонение от которых расстрел.
А в топике художественная самодеятельность и штаны на лямках.

Вы считаете, что кто-нибудь на данном этапе способен сформулировать жесткие требования? Вам известны конфигурации, построенные на принципе модульности, чтобы подсмотреть там паттерны?
63. Алексей Белоусов (AllexSoft) 27.06.13 16:42
(62) Elisy, а почему было бы не организовать передачу данных между модулями через Web-сервисы и XDTO ? помоему универсальнее было бы чем через интерфейсы менеджеров подсистем. Тогда бы много проблем решалось с корректностью данных в общих регистрах, ведь был бы один общий интерфейс читающий и записывающий данные в регистр, а модули расширения которые идут к головному модулю обращались бы к данным через веб сервисы головного модуля. Можно было бы написать стандарты ответов веб сервисов и стандарты интерфейсов, кстати это бы упростило и получение данных из внешних источников которые работают с SOAP. Получалась бы гораздо более широкая модульность чем сугубо в рамках платформы (и даже одной конфигурации) 1С
64. Сергей Карташев (Elisy) 27.06.13 18:04
(63) AllexSoft,
(62) Elisy, а почему было бы не организовать передачу данных между модулями через Web-сервисы и XDTO ? помоему универсальнее было бы чем через интерфейсы менеджеров подсистем. Тогда бы много проблем решалось с корректностью данных в общих регистрах, ведь был бы один общий интерфейс читающий и записывающий данные в регистр, а модули расширения которые идут к головному модулю обращались бы к данным через веб сервисы головного модуля. Можно было бы написать стандарты ответов веб сервисов и стандарты интерфейсов, кстати это бы упростило и получение данных из внешних источников которые работают с SOAP. Получалась бы гораздо более широкая модульность чем сугубо в рамках платформы (и даже одной конфигурации) 1С

Текущий подход не запрещает сделать такой обмен между модулями сторонним вендорам. Если такой способ будет удобным, все его смогут взять на вооружение. Мы планируем пока организовать шину данных для обмена между одноименными модулями, расположенными в SaaS и интегрированными локально к пользователю.
65. Евгений Фамилия (internetname) 27.06.13 18:04
66. Олег (Sol) 27.06.13 18:53
(48) Elisy, это статья каких времен? За это время БСП изменилась кардинально, в плане "модульности" внедрения.
67. Сергей Карташев (Elisy) 27.06.13 20:18
(66) Sol, современная БСП префиксы добавляет своим объектам?
68. zaebunga (1c-intelligence) 27.06.13 21:11
(62) Elisy, не стоит слепо игнорировать регламенты, доминирование, унижение и телесные наказания. WalterMort прав: модульность можно обеспечить правилами. Просто никто не пробовал.

Тут все будет зависеть от владельцев экосистемы.
69. Владимир (hogik) 27.06.13 22:02
(2)(40)
Понятие модуль - растяжимое. ;-)
Думаю, автору публикации имеет смысл дать своё определение этому понятию.
P.S.
"Создание модуля с нуля за 5 минут"
http://codup.com/uroki-openerp/razrabotka/162-urok-3-sozdanie-modulya-s-nulya-za-5-minut.html
"Создание меню в OpenERP 6.1"
http://codup.com/uroki-openerp/razrabotka/165-urok-4-sozdanie-menyu-v-openerp-6-1.html
Прикрепленные файлы:
OpenERP_Technical_Memento_latest.pdf
sikuda; Elisy; +2 Ответить
70. Сергей Карташев (Elisy) 28.06.13 05:16
(68) zaebunga,
(62) Elisy, не стоит слепо игнорировать регламенты, доминирование, унижение и телесные наказания. WalterMort прав: модульность можно обеспечить правилами. Просто никто не пробовал.
Тут все будет зависеть от владельцев экосистемы.

Не было стремления игнорировать их. Я пытался донести мысль, что пока не появится штук 20 модулей от разных производителей, сложно сформулировать требования, а тем более жесткие требования.
71. zaebunga (1c-intelligence) 28.06.13 06:02
(70) Elisy, ничего страшного в этом нет - можно написать те правила, которые известны на данный момент. И добавить в конце пункт - "Владелец Экосистемы имеет право вносить в правила любые изменения, с уведомлением за 30 дней до начала применения. По истечении 30 дней модули, не прошедшие проверку по новым правилам, будут сливаться в отстойник к херам".
72. ivanov660 ivanov660 (ivanov660) 30.06.13 21:07
Почему бы не рассматривать разграничение в рамках модульности на уровне интерфейса (универасльного), на подобии использования внешних компонент для 1С, подключений различных плагинов и т.д., соответственно отпадет масса проблем связанных с взаимной интеграцией модулей друг в друга и других вытекающих последствий?
73. Сергей Карташев (Elisy) 01.07.13 04:37
(72) ivanov660,
Почему бы не рассматривать разграничение в рамках модульности на уровне интерфейса (универасльного), на подобии использования внешних компонент для 1С

Внешние компоненты Native API не несут функциональности по интерфейсу. Можно рассмотреть вариант интеграции по html. Например, формирование рабочего стола при загрузке 1С из разных модулей.
74. Сергей Карташев (Elisy) 01.07.13 09:33
По ходу реализации возникла проблема вывода из модулей форм АРМ в рабочую область начальной страницы
Более подробно о проблеме можно почитать в ветке форума.
Как программно управлять начальной страницей?
76. Руслан Климачев (krv2k) 10.07.13 17:48
(0) Модульность - вещь, конечно, интересная, но, на первый взгляд, идея кажется утопичной. Если отследить связи и их корректность между ядром и дополнительным модулем еще представляется возможным, то обеспечить корректное взаимодействие между модулем "А" и модулем "Б" разных разработчиков - очень сложно. А если на это наложить разные версии ядра и модулей, то почти нереально.
Вы говорите, что модульность упростит разработку и поддержку, - это не так. Пусть количество жестких ссылок и уменьшится, но сложность логических связей никуда не исчезнет, а, наоборот, даже возрастёт, так как эти связи нужно будет продумывать более тщательно.
Даже вендор, разрабатывая целостные системы, не использует принцип модульности, и всё из-за того, что такие системы гораздо сложнее разрабатывать, чем "монолиты". На эту тему было несколько лет назад интервью.

При текущем функционале платформы кажутся реальными следующие варианты:
1) Разработать свою целостную модульную систему. Вариант, думаю, выполним, но SaaS и функциональные опции также решают эту проблему, причем, с меньшими затратами.
2) Разработать Ядро и дать возможность разрабатывать к нему дополнительные модули, взаимодействие между ними запретить. Но здесь уже вызывает сомнение востребованность такого решения.

Во всяком случае, желаю вам удачи, задумка у вашего проекта интересная!
AllexSoft; Elisy; +2 Ответить
77. Алексей (fgremlin) 10.07.13 19:44
Тоже вставлю свои 5 коп. в разговор:
1. Сама идея модульности давно витает в воздухе, но очень сложно реализуема [IMHO].
Сложности во все происходящее добавляет ограниченность платформой 1С. Мне кажется, что все фишки, добавленные в 8-й платформе и её развитии подвели только к идеям энтузиастов о модульности, но реально не дают достаточно инструментов для её реализации. Вот попробуйте сформировать для себя те же цели и задачи не привязываясь к платформе... абстрагируйтесь от платформы и прикиньте какими способами можно было-бы достичь тех же целей. Конечно удобно взять такой инструмент как 1С и не морочиться вопросами хранения данных, организации структуры данных на других уровнях заняться исключительно работой процессов и пр. но есть ограничения которые вынуждают искать обходные варианты решения и они не добавят решению ни сопровождаемости ни скорости.
2. Мне кажется в задаче потребуется добавлять некие модули, которые должны будут отвечать за интеграцию модулей между собой, чтобы в простой и удобной форме все это настраивалось (раз уж проект ориентирован на доступность и удобность системы). И еще, наверное имеет смысл сделать модули атомарнее, менее масштабные по функциональности, но менее зависимые по связям с окружающими (просто мысль). Тогда будет соблюдаться идея Доминиканы про "конструктор LEGO" но есть трудность, как связать разношерстность модулей отвечающих за хранение (запись данных), выборку данных, реализацию интерфейсов и пр.
Да, вот, модули нужно разбить функционально чтобы для каждой функции проработать свои интерфейсы и свои инструменты реализации каких-то общих функций для реализации интегрированности.
78. Алексей (fgremlin) 10.07.13 19:50
И еще архитектурные мысли в догонку:
[IMHO] нужно сделать некое ядро общих модулей с общими интерфейсами, которые будут обеспечивать связи между модулями, проверки наличия нужных модулей, инструменты связи функционала модулей, их взаимодействия и пр.
79. Сергей Карташев (Elisy) 10.07.13 20:12
Спасибо всем за ваши ценные комментарии.
Сейчас в нашей системе несколько модулей: Базовые справочники, Задачи, Управление клиентской базой, База знаний
Разрабатывается центральный для всех модуль Процессная шина.
Эти несколько модулей позволяют сформулировать требования к оформлению модулей. Сейчас известно, что каждый модуль будет сопровождаться функциональной опцией для всех своих элементов. Подсистемы модулей будут помещены в подсистему Модули. Будут интерфейсные подсистемы, расположенные в корне подсистем, чтобы можно было их показывать в панели разделов.
От хранения списка модулей в параметрах сеанса, скорее всего, придется отказаться.
80. Евгений Пономаренко (Evgen.Ponomarenko) 11.07.13 00:45
Я полностью поддерживаю идею модульности... мало того, уже 5 лет её активно эксплуатирую и развиваю.
Пришлось выкинуть УТП НА ПОМОЙКУ и начать все с нуля. В системе всего порядка 60 тыс. строк кода, чешутся руки
оставить только 30. Механизмы 1С используются процентов на 5 :))). По функциалу система учетных модулей не уступает УТП.
В плане интерфейса - превосходит на порядок. Проблемы с производительностью отсутствуют как класс.

Как показал опыт создать экосистему из 120 независимых учетных модулей не составляет никакой трудности. Просто модули не должны вызывать друг друга, а использовать общую шину данных и Единые стандартные библиотеки (ЕСБ) примитивных атомарных функций.
В отличие от Библиотеки стандартных подсистем (БСП) глубина вложенности функций ЕСБ не более 2-х.

Для бизнес-приложений достаточно 7-ми базовых регистров.
В основе каждого модуля - лежит основной запрос. Модули полностью конструируется. Обработчики событий подключаются на лету.
Сам модуль - практически не содержит программного кода... Ну разве, что для красоты ))))) можно в событии "после выполнения запроса" разукрасить текст и долепить картинки. Для функционирования модулей используется
набор стандартных библиотек, хранимых в конфигурации, и обновляемые крайне редко.

Сами модули хранятся в базе данных, могут кочевать из одной базы в другую при условии, что базы имеют стандартные библиотеки одной версии.
Модули могут быть легко удалены или инсталированы. Есть проблема - тексты модулей невозможно зашифровать, так как увы, они не содержат функционального кода. Модули легко сохраняюмся в xml штатными средствами 1С.
И могут быть импортированы в любую другую программную среду поддерживающую скрипты. Например PHP+MySQL или VBA+MsSQL.

Есть одно большое НО проектировать "учетные модули" должны не программисты, а прикладные специалисты: управленцы, экономисты и финансисты.Задача программистов - технически обеспечить экосистему взаимодействия "Учетных модулей"
81. Алексей Белоусов (AllexSoft) 11.07.13 09:17
(80) Evgen.Ponomarenko, не хотите написать статью, с примерами и скриншотами ? тут всем было бы интересно увидеть реально функционирующую модульную систему
82. Алексей (fgremlin) 11.07.13 09:30
(80) Evgen.Ponomarenko,

Очень интересно, присоединяюсь к (81) AllexSoft.
83. Orion Zakirov (terrorion) 11.07.13 09:38
(80) Evgen.Ponomarenko,
тоже любопытно взглянуть
84. Михаил Ражиков (tango) 11.07.13 13:43
(80) Evgen.Ponomarenko,
не программисты, а прикладные специалисты
а кто должен будет объяснить им, чего от них надо-то?
85. Михаил Ражиков (tango) 11.07.13 13:44
(80) Evgen.Ponomarenko,
Задача программистов - технически обеспечить экосистему
А!
86. Евгений Пономаренко (Evgen.Ponomarenko) 11.07.13 22:20
(81) AllexSoft,

(80) Evgen.Ponomarenko, не хотите написать статью, с примерами и скриншотами ?
тут всем было бы интересно увидеть реально функционирующую модульную систему

Честно говоря, уже даааавно чешутся руки и статью написать и демо-версию выложить...
Но хочется сделать хорошо, а времени на это пока хватает. Сейчас по неволе работаю спасателем одного
безнадежно убитого проекта. Проект вышел из комы. Состояние клиента - стабильно тяжелое.

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

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

Система разрабатывалась силами 3-х человек: один идеолог, один разработчик + один специалист технической поддержки.
Когда пришло осознание новизны автор концепции издал книгу "Управление реальным предприятием. Новая концепция."
автор - Кустов Михаил Геннадиевич.
В книге описана простым языком математика, которая легла в основу прикладного конструктора модулей.
Так, что всему свое время )))) будут и примеры, будут и скриншоты )))))
87. Евгений Пономаренко (Evgen.Ponomarenko) 11.07.13 22:21
(85) tango,

Многоуважаемый Михаил, я не понял вашего вопроса - уточните его плиззз.
88. Алексей Белоусов (AllexSoft) 14.07.13 23:34
(86) Evgen.Ponomarenko, ждем с нетерпением
89. Александр Якимов (yackimoff) 06.08.13 22:17
Несмотря на то, что 1С выпустила БСП, как шаг к модульности приложений, хотелось бы видеть несколько альтернативных подходов.

Зачем? В БСП, (особенно в последних версиях — 2.1.5), подход к модульности кажется достаточно глубоко продуманным. Учитывая, что БСП де-факто есть и (или) будет must-have для вновь создаваемых конфигураций, пытаться предложить свой несовместимый (читай, нестандартный) подход, по меньшей мере, недальновидно.

В предложенном решении за нахождение модулей отвечает загрузчик, который ищет модули в конфигурации и составляет из них список.

Практически то же самое уже есть в БСП. См. функцию ОписанияПодсистем().

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

Это вообще никуда не годится — делать фейковую подсистему, которая будет играть роль индикатора того, что это — модуль. Подсистемы преднзначены не для этого. Вы пытаетесь использовать предложенные платформой технологии не по назначению, и предлагаете сделать это стандартом.

Система интерфейсов позволяет обеспечить слабую связанность модулей и подписку на глобальные события системы. Выгода в том, что вызывающий модуль может не знать, кто подписан на него, а вызываемый модуль не будет содержать статической ссылки на вызывающий модуль.

Что-то подобное («подписка» модуля на «события» подсистем) уже есть в БСП 2.1.5.

Модульные приложения часто должны предоставлять цельный интерфейс для пользователя, когда один модуль отвечает за одну часть элементов управления, а другой модуль - за другую часть.

По-моему, это — зло. Интерфейсы должны прорабатываться дизайнером интерфейсов. Если у вас в интерфейсе задействованы несколько «независимых» модулей, то, наверное, лучше стоит сделать несколько продуманных интерфейсов для каждого случая комбинации этих модулей.

Понятно, что модульность снижается, однако, тут уже вопрос приоритетов; о ком вы больше заботитесь: о пользователе или о разработчике.
90. Сергей Карташев (Elisy) 07.08.13 06:08
(89) yackimoff,
Зачем? В БСП, (особенно в последних версиях — 2.1.5), подход к модульности кажется достаточно глубоко продуманным. Учитывая, что БСП де-факто есть и (или) будет must-have для вновь создаваемых конфигураций, пытаться предложить свой несовместимый (читай, нестандартный) подход, по меньшей мере, недальновидно.

БСП не реализует всей необходимой нам функциональности, требуемой для сосуществования независимых модулей в одной системе, в т.ч. от разных поставщиков, под управлением другой экосистемы. Более подробно можете почитать в моем комментарии (28)
Сущаествуют разные подходы. И непонятно, почему предложенный нами подход обязан быть совместимым именно с БСП. Подходы к модульности изучены в других более распространенных системах: Java, .Net - на основе их был спроектирована данный в стстье подход.

Практически то же самое уже есть в БСП. См. функцию ОписанияПодсистем().

Предложенная вами функция поддерживает версионирование, обновление на уровне модулей, а также возможность подключать и отключать каждый модуль со стороны внешней экосистемы?

Это вообще никуда не годится — делать фейковую подсистему, которая будет играть роль индикатора того, что это — модуль. Подсистемы преднзначены не для этого. Вы пытаетесь использовать предложенные платформой технологии не по назначению, и предлагаете сделать это стандартом.

Какие мы нежные. Можно поинтересоваться, для чего предназначены подсистемы? Посмотрите в БСП функцию ПодсистемаСуществует. Подсистемы - это попытка 1С классифицировать огромное множество объектов в конфигурации. Именно по прямому назначению они и используются в нашем подходе. Кстсти, в текущей реализации убрана "фейковая" подсистема "МенеджерМодуля" и модули помещены в один уровень в подсистему Модули.

По-моему, это — зло. Интерфейсы должны прорабатываться дизайнером интерфейсов. Если у вас в интерфейсе задействованы несколько «независимых» модулей, то, наверное, лучше стоит сделать несколько продуманных интерфейсов для каждого случая комбинации этих модулей.

Вы имеете право на свою точку зрения, но она не обязательно будет совпадать с общепринятой. Лучшее- враг хорошего.
Пока 1С в своей изолированной песочнице создает БСП и восторгается творением, в мире люди продвинулись намного дальше:
http://habrahabr.ru/post/176895/
Сейчас БСП спотыкается при усложнении интерфейса. Например, дизайнер интерфейсов проработал АРМ менеджера по продажам, где в одной форме доступен ввод нового Клиента и нового Контактного Лица. У двух объектов поддерживается контактная информация и дополнительные свойства. БСП не поддерживает свойства и контактную информацию для двух разных объектов на одной форме.

PS. Последние исследования в области упрвляемого интерфейса 1С показывают, что для управляемого интерфейса 1С необходимо разрабатывать альтернативу с использованием HTML5 и JS. Текущий интерфейс УФ убогий, не поддерживает определяемых пользователем контролов, содержит массу ошибок. Вероятность получить адекватный задуманному интерфейс на HTML+JS намного выше, чем на управляемых формах.
91. Александр Якимов (yackimoff) 07.08.13 10:03
БСП не реализует всей необходимой нам функциональности, требуемой для сосуществования независимых модулей в одной системе, в т.ч. от разных поставщиков, под управлением другой экосистемы.


Я говорил, скорее, не про саму БСП, сколько про эволюционирующий там подход к интеграции различных подсистем.

Конечно, возможно, что ни в самой БСП, ни в её техниках нет всей нужной функциональности. Но зачем подменять ту, что есть?

почему предложенный нами подход обязан быть совместимым именно с БСП. Подходы к модульности изучены в других более распространенных системах: Java, .Net


Потому что, как мне кажется, перенос Java или .Net-подходов в 1С будет во многом искорежен адаптацией и техническими ограничениями.

Да и, все-таки, философия такая у 1С:Предприятия, что конфигурация должна быть единой и целостной. В этом свете, говорить о модульности, возможно, стоит до какой-то определенной степени.

[IS-QUOTE]Практически то же самое уже есть в БСП. См. функцию ОписанияПодсистем().


Предложенная вами функция поддерживает версионирование, обновление на уровне модулей, а также возможность подключать и отключать каждый модуль со стороны внешней экосистемы?[/IS-QUOTE]

Версионирование и обновление — да. А вот подключение и отключение модуля — что вы имеете в виду? Если просто включение и отключение функционала, то ведь для этого есть средства: например, функциональные опции.

Какие мы нежные. Можно поинтересоваться, для чего предназначены подсистемы? Посмотрите в БСП функцию ПодсистемаСуществует. Подсистемы - это попытка 1С классифицировать огромное множество объектов в конфигурации. Именно по прямому назначению они и используются в нашем подходе. Кстсти, в текущей реализации убрана "фейковая" подсистема "МенеджерМодуля" и модули помещены в один уровень в подсистему Модули.


Подсистемы предназначены для объединения объектов метаданных в группы по функционально-прикладному смыслу. У вас же МенеджерМодуля или Модули — это квазиподсистемы. Они играют роль признаков. Вы в них заведомо будете вынуждены снимать галку «Включена в интерфейс» и заведомо оставлять пустую справочную информацию. Т. е. вы заведомо их используете не на 100% и не можете использовать на 100%. Отсюда вывод — используете не по назначению. Просто, не совсем ясно, зачем использовать подсистемы для этого — для признака? Можно же, например, просто требовать специального наименования модуля, образованного по правилу от имени подсистемы, или использовать комментарий модуля, или использовать макеты с описаниями и т. д.

Вы имеете право на свою точку зрения, но она не обязательно будет совпадать с общепринятой.


Какую вы называете общепринятой?

Сейчас БСП спотыкается при усложнении интерфейса...


Опять же, я говорил не про саму БСП, а про подходы к модульности, использованные в ней.

Текущий интерфейс УФ убогий...


С этим я не спорю, но мы отвлеклись от модульности.
92. Сергей Карташев (Elisy) 07.08.13 13:11
Я говорил, скорее, не про саму БСП, сколько про эволюционирующий там подход к интеграции различных подсистем.
Конечно, возможно, что ни в самой БСП, ни в её техниках нет всей нужной функциональности. Но зачем подменять ту, что есть?

Очень приятно, что БСП не стоит на месте и развивается, я искренне рад за нее. Эволюционирующий подход - это процесс, а нужен результат - функционал здесь и сейчас. У нас сейчас есть БСП в системе, но я лично ее использую на уровне 2х функций: разложить строку в массив строк и склеить строку из массива. Кроме этих 2х функций в БСП есть один огромный недостаток - отстутствие префиксов/постфиксов для объектов БСП, что затрудняет интеграцию с другими системами.

Потому что, как мне кажется, перенос Java или .Net-подходов в 1С будет во многом искорежен адаптацией и техническими ограничениями.

Это проблемы 1С. Стоит заметить, что БСП пытается расширить рамки 1С. Например, общие модули с постфиксом "Переопределяемый" есть ни что иное, как попытка разработчиков реализовать override-методы из ООП.

Да и, все-таки, философия такая у 1С:Предприятия, что конфигурация должна быть единой и целостной. В этом свете, говорить о модульности, возможно, стоит до какой-то определенной степени.

Вы очень лестно отзываетесь о попытках 1С развивать свою платформу - философией эти попытки назвать язык не поворачивается. Философия в моем понимании - стройная система возможностей системы, а не набор костылей к недостаткам функционала.

Версионирование и обновление — да. А вот подключение и отключение модуля — что вы имеете в виду? Если просто включение и отключение функционала, то ведь для этого есть средства: например, функциональные опции.

Да, подключение и отключение модулей у нас сейчас реализовано через функциональные опции.

Подсистемы предназначены для объединения объектов метаданных в группы по функционально-прикладному смыслу. У вас же МенеджерМодуля или Модули — это квазиподсистемы. Они играют роль признаков. Вы в них заведомо будете вынуждены снимать галку «Включена в интерфейс» и заведомо оставлять пустую справочную информацию. Т. е. вы заведомо их используете не на 100% и не можете использовать на 100%. Отсюда вывод — используете не по назначению. Просто, не совсем ясно, зачем использовать подсистемы для этого — для признака? Можно же, например, просто требовать специального наименования модуля, образованного по правилу от имени подсистемы, или использовать комментарий модуля, или использовать макеты с описаниями и т. д.

Повторюсь, что в БСП наличие или отстутствие функционала определяется через проверку наличия подсистемы в конфигурации. Приятно было бы видеть ветку в конфигураторе Модули и необходимые нужные нам настройки, но за неимением такого используем подручные средства. Кстати, использование комментария для хранения метаинформации тоже не по назначению. Использовать имя в качестве определителя - плохой стиль - все равно, что определять тип переменной в зависимости от названия переменной.

Какую вы называете общепринятой?

Общепринятая точка зрения - я имел ввиду международного сообщества - точка зрения в сообществах намного превышающих сообщество 1С.
93. Сергей Карташев (Elisy) 16.08.13 16:58
В продолжение модульности предлагаю обсудить тему сложных интерфейсов с повтоным использованием регионов форм.
http://forum.infostart.ru/forum90/topic91727/
94. Яков Коган (Yashazz) 15.07.15 19:36
И вот тут ррраз, и появляется идеология подсистем в 8.3.6... Кто что думает?
95. Сергей Карташев (Elisy) 16.07.15 06:19
(94) Yashazz,
Сначала не мешает ознакомиться с идеологией. Нет ссылки на представление идеологии от 8.3.6?
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа