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

28.06.13

Разработка - Рефакторинг и качество кода

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

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

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

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

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

Интересным является обработчик переопределения открытия форм ОбработкаПолученияФорм в менеджере объекта . В случае, если есть главный и зависимый модуль, зависимый модуль может реализовать свою новую форму, включающую функциональность главного модуля и свой. Затем через ОбработкаПолученияФорм подменить своей формой форму главного модуля. Например, есть модуль продажи и зависимый от него модуль резервирования. Модуль продажи содержит свою форму документа реализации, которая показывается, если не подключен модуль резервирования. Как только в системе появляется модуль резервирования, он может переопределить форму продажи, дополнив ее своими реквизитами. При таком подходе модуль продаж может даже не догадываться о существовании модуля резервирования.

См. также

Когда понадобился новый оператор

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

18.03.2024    1162    ZhokhovM    2    

4

Когда разработчик платформы не добавил проверку препроцессоров

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

18.03.2024    2690    ZhokhovM    4    

9

Реструктуризация - бесконечная история

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при масштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».

29.09.2023    1910    1CUnlimited    15    

22

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 2

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Коротко о том, как я перестал быть создателем макаронного кода и непроходимых джунглей методов и модулей. Расскажу о том, что реально применяю на практике с примерами при разработке (а в основном доработке) в типовых конфигурациях 1С. Комментарии очень приветствуются.

27.09.2023    6970    Lemmonbri    136    

36

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 1

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Коротко о том, как я перестал быть создателем макаронного кода и непроходимых джунглей методов и модулей. Расскажу о том, что реально применяю на практике с примерами при разработке (а в основном доработке) в типовых конфигурациях 1С. Комментарии очень приветствуются.

19.09.2023    4350    Lemmonbri    16    

31

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

Нашей компании часто приходится сталкиваться с обновлением конфигураций разной степени переписанности. Какие-то из них обновляются легко, какие-то — не очень. Расскажем о некоторых принципах модификации программы, которые помогут сделать последующий процесс обновления легче. Или тяжелее, если стараться их не соблюдать.

10.08.2023    9590    0    1c-izhtc    37    

21

Задача на ошибки и неоптимальности при проведении приходной накладной

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Задачу эту дают на собеседованиях, видимо, те франчи, которые не в состоянии оценить человека по резюме и в ходе беседы. По идее задачи, подобные этой, должны давать начинающим студентам. Но дают всем подряд. Итак: мои 5 копеек. Критика приветствуется.

11.07.2023    2214    magic1s    32    

11
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. pahich 723 25.06.13 22:30 Сейчас в теме
С программным созданием элементов все ясно и понятно. Но вопрос в следующем - Как назначить программно созданной кнопке глобальную команду? Не так давно разбирался с данным вопросом и не нашел ответа (м.б. с выходом 8.3.3 что то поменялось?). Если ответ на данный вопрос все еще остается "никак", тогда каким образом будут реализовываться вызовы команд одного модуля из формы, скомпилированной для 2х модулей?
8. Elisy 948 26.06.13 07:21 Сейчас в теме
(1) pahich,
С программным созданием элементов все ясно и понятно. Но вопрос в следующем - Как назначить программно созданной кнопке глобальную команду? Не так давно разбирался с данным вопросом и не нашел ответа (м.б. с выходом 8.3.3 что то поменялось?). Если ответ на данный вопрос все еще остается "никак", тогда каким образом будут реализовываться вызовы команд одного модуля из формы, скомпилированной для 2х модулей?

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

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

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

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

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

Второй способ - подмена формы, скомпилированной для 2х модулей через ОбработкаПолученияФорм
23. AllexSoft 26.06.13 12:39 Сейчас в теме
(8) вот еще вопрос, какая то система лицензирования модулей разрабатывается? какая то система защиты от копирования может будет? я думаю модули платные то будут восновном
46. Elisy 948 26.06.13 18:46 Сейчас в теме
(23) AllexSoft,
(8) вот еще вопрос, какая то система лицензирования модулей разрабатывается? какая то система защиты от копирования может будет? я думаю модули платные то будут восновном

Сейчас не ставим такой задачи. Предполагается, что модули будут в основном использоваться в облаке, к которому доступ на уровне кода будет ограничен. Можно со временем продумать совместно какие-то механизмы, например, подписывание. Выгоднее, конечно, работать с платными модулями.
2. sikuda 673 25.06.13 22:58 Сейчас в теме
Переосмысление монолита 1С? Очень хорошо. Посмотрите на openerp.com там уже давно модульная система. Для конкуренции на западе надо делать на удобнее...
40. RustIG 1351 26.06.13 18:13 Сейчас в теме
(2) sikuda, картинки красивые, как будто бы "модульные" :)
а что внутри? обычная база данных и никакой модульности? ;)
69. hogik 443 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 Ответить
3. Begemoth80 267 25.06.13 23:14 Сейчас в теме
В некоторых применениях БСП может не подойти.

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

Кажется, что такая сравнительная табличка:
- Поможет оценить полезность подхода в целом
- Позволит выделить ключевые механизмы нового подхода
andukin; Chernik; Makushimo; Elisy; +4 Ответить
4. tango 506 26.06.13 00:08 Сейчас в теме
(3) Begemoth80,
Приведите пожалуйста сравнение вашего подхода с подходом БСП
поясните, пожалуйста, что вы понимаете под термином (или где/в чем вы увидели) "подход БСП"
6. Begemoth80 267 26.06.13 06:22 Сейчас в теме
(4) tango,
Подход БСП описан, например, в статье на ИТС "Разработка конфигураций с повторным использованием общего кода и объектов метаданных" http://www.its.1c.ru/db/v8std#content:2149184200:1

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

имеет в виду что-то другое, тогда он напишет об этом явно
12. tango 506 26.06.13 10:56 Сейчас в теме
(6) Begemoth80, БСП как бы описан, да
нет - описания подхода БСП
**
если кто-то таки этот подход увидит, следуют ли разработчики БСП предполагаемой декларации?
29. Begemoth80 267 26.06.13 13:28 Сейчас в теме
(12) tango,
нет - описания подхода БСП

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

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

Этот подход можно увидеть в типовых конфигурациях, которые "стоят на поддержке" у БСП
44. RustIG 1351 26.06.13 18:30 Сейчас в теме
(29) текст и информация реально сложно воспринимается, темы статей - не актуальные: РЛС, переопределяемые модули, совместимости библиотек - далеко от жизни клиентов.
да уж, сделайте жизнь 1С-ника легче пож-та: растолкуйте простыми словами :)
39. RustIG 1351 26.06.13 18:11 Сейчас в теме
(6) сырая статья на ИТС :(
хоть бы постыдились такую ссылку давать ;)
28. Elisy 948 26.06.13 13:24 Сейчас в теме
(3) Begemoth80,
Приведите пожалуйста сравнение вашего подхода с подходом БСП (и платформы).
Из сравнение должно стать понятно:
- Какие есть минусы в БСП, которые нельзя обойти локально (требуется придумывать новый подход)
- Какие реальные задачи предлагаемый подход решает радикально лучше, чем подход БСП (платформы)
- У нового подхода нет явных минусов (т.е. нет задач которые бы он решал значительно хуже чем БСП)

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


Идеи немного различаются. БСП предлагает вобрать в себя всю чаще всего используемую функциональность и оформить ее в виде библиотеки. Эту библиотеку можно встраивать в готовые конфигурации или основывать на ней новые конфигурации. Конфигурации на основе БСП всем известны УТ, УНФ, Документооборот - это монолитные системы, где подсистемы-модули тесно связаны между собой.
Модульный подход, предложенный в статье, задается вопросом - можно ли разделить конфигурацию 1С на множество модулей и обеспечить слабую связь между ними. Это нужно для того, чтобы сторонние разработчики могли независимо писать и предлагать свои модули. Слабая связь между модулями позволит вести более легкую независимую поддержку модулей различных авторов. Обновления одних модулей с меньшей вероятностью вызовут конфликт с модулями других разработчиков. Модульность позволит навести порядок в системе, а в далеком будущем организовать магазин приложений, в т.ч. в облаке по подписке.
Имеет смысл оценивать разные идеи: идею повторного использования кода (БСП) против пакетирования (статья)? Если имеет, то давайте выработаем совместно критерии для оценки - по каким параметрам будем оценивать.
Навскидку:
Уникальность имен: БСП не обеспечивает уникальность имен для своих объектов, что приводи к проблемам, например, таким: http://infostart.ru/public/121312/ Цитирую: "в «1С» решили, что «БСП – это основа» и поэтому ей не нужны префиксы ... Ведь это же «библиотека»."
В посте предлагается выработать заранее соглашение на этот счет.
33. MSensey 49 26.06.13 15:02 Сейчас в теме
(28) БСП не монолитная библиотека. Часть ее подсистем может внедряться отдельно.
34. obemgyorik 99 26.06.13 15:12 Сейчас в теме
(33) Для внедрения подсистемы БСП необходима работа программиста. Наша задача, чтобы при покупке нового модуля, автоматически делалась поставка, на которую клиент мог бы обновиться, не тратя на это обновление времени специалистов (в случае, если клиент работает в модели SaaS - даже не выгоняя из базы пользователей). По принципам и механизмам поставки отдельных модулей в данный момент готовится статья.
37. MSensey 49 26.06.13 16:41 Сейчас в теме
(34) Наша задача, чтобы при покупке нового модуля, автоматически делалась поставка
Об этом в публикации ничего не написано.
Но сама задача отказа от специалиста кажется надуманной.
Реализовать крупную систему, наращивая слабо связанные модули невозможно.
Например, упомянутое резервирование, не сделать на принципах модульности. Оно зависит от того как организован учет товаров, учет товаров зависит от НСИ товаров.
В большинстве случаев отказаться от специалиста по внедрению не получится.
Специалист должен проанализировать возможность встраивания нового модуля.

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

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

Проблема уникальности названий от разных разработчиков в рамках одной конфигурации решается.
Не решается т.к. разные разработчики модулей могут дать одинаковые префиксы.
38. MSensey 49 26.06.13 17:03 Сейчас в теме
(37) Реализовать крупную систему, наращивая слабо связанные модули невозможно.
Здесь я имею ввиду следующее.
Значительную часть системы составляют модули, которые сильно взаимодействуют друг с другом.
Их можно реализовать как модули, но они будут совместимы только с модулями того же разработчика.
Модули разных разработчиков в большинстве случаев не будут взаимодействовать, либо будут слабо взаимодействовать, да и то с заранее определенными модулями.
41. V.Nikonov 120 26.06.13 18:16 Сейчас в теме
(38) MSensey В любом случае, уйти от многообразия и вариативности мира не получится.
Разумеется, что возможно на ограниченном временном этапе сделать силами сторонних разработчиков модули достаточно совместимые...
Модульная разработка - практикуется очень давно. Думается и дальше будет процветать объектная модель разработки. Не вижу радикального отличия от данного принципа.
Предполагаю, что рынок разработки модулей, как дополнительных подсистем будет развиваться. Естественным требованием станет описание "внешних интерфейсных объектов, функций" и т.п. Модули будет собирать Программист-Компоновщик. Именно он будет нести ответственность за взаимодействие используемых модулей. Не думаю, что конечный пользователь сможет самостоятельно приклеивать к собственной системе сторонние модули (только, если модуль совсем автономный)...
45. frying 21 26.06.13 18:45 Сейчас в теме
(38),
На данный момент мы разрабатываем менее "связанный" модуль - CRM, нежели продажи, заказы и резервирование. На примере его реализации посмотрим насколько реально все остальное. Скорее всего, в результате, деление на модули пойдет от того, что получится разделить функционально (это личное мнение). Также модули реализующие дублирующий функционал типовых решений 1С на данный момент не рассматриваются.
48. Elisy 948 26.06.13 19:04 Сейчас в теме
(33) MSensey,
(28) БСП не монолитная библиотека. Часть ее подсистем может внедряться отдельно.

Особенно странной в этой связи выглядит статья: http://infostart.ru/public/121312/
Ну и конфигурациям УТ, УНФ, основанным на БСП, ее "немонолитность" не слишком помогла. Они как были монолитными в 8.0, так и остались в 8.3.
У БСП однозначно есть, чем гордиться. Большинство модулей мы разрабатываем с оглядкой на БСП, как своего рода стандарт. Но под наши задачи, к сожалению, она в полном объеме не подходит.
66. Sol 54 27.06.13 18:53 Сейчас в теме
(48) это статья каких времен? За это время БСП изменилась кардинально, в плане "модульности" внедрения.
67. Elisy 948 27.06.13 20:18 Сейчас в теме
(66) Sol, современная БСП префиксы добавляет своим объектам?
5. CheBurator 3119 26.06.13 04:07 Сейчас в теме
бубуд ли на основе данного подхода в результате вашей работы/проекта - какая-нибудь простая, но функциональная ПРИКЛАДНАЯ ДЕМОКОНФА (например, простой торговый учет остатки+резервы, с возможностью отдельного подключения/отключения модулей - особенно интересно посмотреть как это будет сделано при возможно более меклом количестве статических связей между модулями...)
SeiOkami; SirYozha; +2 Ответить
30. Elisy 948 26.06.13 13:41 Сейчас в теме
(5) CheBurator,
будут ли на основе данного подхода в результате вашей работы/проекта - какая-нибудь простая, но функциональная ПРИКЛАДНАЯ ДЕМОКОНФА (например, простой торговый учет остатки+резервы, с возможностью отдельного подключения/отключения модулей - особенно интересно посмотреть как это будет сделано при возможно более меклом количестве статических связей между модулями...)

Демоверсии, к сожалению, не планируется. Ограниченное время не позволяет. Встала задача организовать комфортное существование наших и сторонних модулей внутри одной будущей системы. Принцип, предполагается, взять как описано в статье. Сейчас важно собрать критику, отзывы и пожелания, чтобы не заложить ошибку в фундамент.
Какую пользу это даст сообществу: будущая система, планируется, будет состоять из множества модулей. Разработчикам с Инфостарта будет интересно заниматься написанием дополнительных модулей или доработкой существующих. Может быть откроется магазин приложений.
36. CheBurator 3119 26.06.13 16:21 Сейчас в теме
(30) ну и зря... рожать идеи и инструименты - это хорошо.. ровно до тех пор пока этим инструиментом не начать строгать предмет.. тут и выяснится - ручка не с той стороны.. заточка лезвия не под тем углом...
wolfsoft; zqzq; AllexSoft; Elisy; +4 Ответить
49. Elisy 948 26.06.13 19:08 Сейчас в теме
(36) CheBurator,
(30) ну и зря... рожать идеи и инструименты - это хорошо.. ровно до тех пор пока этим инструиментом не начать строгать предмет.. тут и выяснится - ручка не с той стороны.. заточка лезвия не под тем углом...

Лично я полностью согласен с Вами, но нужно выбирать: выделить ресурсы на демоверсию или продвинуться в рамках поставленных задач. Пока что расклад не в пользу демоверсии.
7. ssn5810 79 26.06.13 07:03 Сейчас в теме
Архив базы с примерами из статьи: Module-application.dt (47,77 kb)- ссылка не работает
31. Elisy 948 26.06.13 14:37 Сейчас в теме
(7) ssn5810,
Архив базы с примерами из статьи: Module-application.dt (47,77 kb)- ссылка не работает

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

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

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

Большую часть этих проверок можно автоматизировать, опять же с помощью новых возможностей платформы (тестируемое приложение).
16. AllexSoft 26.06.13 11:56 Сейчас в теме
(10), (11) zaebunga, ты веришь в это?) если даже в 1С совместимо продуктах зачастую нет второй конфигурации поставщика, тоесть никто не пользуется тем что есть в платформе, думаешь будет кто то пользоваться рекомендациями от БИТ ? ) оочень сомневаюсь. Да и вспомни качество кода написаное другими разработчиками, часто видел код написанный на коленке?) все еще думаешь что будут пользоваться рекомендациями от БИТа ?
Chernik; RustIG; +2 Ответить
18. 1c-intelligence 12771 26.06.13 12:10 Сейчас в теме
(16) AllexSoft, верю конечно.

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

С отраслевыми не1Сными работал - согласен, говно обычно. Потому что цели не было сделать круто. Так, чтобы пацанам было не стыдно показать :)
21. AllexSoft 26.06.13 12:27 Сейчас в теме
(18) zaebunga, со стороны доминиканцев будет сделано максимально красиво, в это можно поверить, но разработчики модулей будут не БИТ, а ребята из франей которым платят за часы и чтобы как то работало на тестовом примерчике. В реале это будет все то же говно, потому что никто за красивость кода и соблюдение стандартов платить никогда не будет.
22. 1c-intelligence 12771 26.06.13 12:39 Сейчас в теме
(21) AllexSoft, если парни из франей не будут следовать правилам - их "модули" останутся жить на их компьютерах, и они не заработают денег в экосистеме. Нахера они там со своим говном.

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

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

Важно, что свой говенный модуль долбо*бы клиенту напрямую будут ставить, а не сам клиент его через экосистему купит.
Ну я так себе это представляю. Цербер должен на входе в экосистему стоять. Типа серьезный фейсконтроль. Кто уперся лбом, сконцентрировался и фейсконтроль прошел - получает вечное наслаждение, пышногрудых дев и бесконечный поток денег - он в СИСТЕМЕ :) Внутри экосистемы церберов уже нет.
Makushimo; +1 Ответить
27. AllexSoft 26.06.13 13:13 Сейчас в теме
(25) zaebunga, я с вами согласен, а что будет если модуль прошел жесткий контроль, его впустили в экосистему, разумеется поставщих начнет делать плюшки к нему, обновлять, а если это будет делать человек-говнокод ? так можно и нормальный модуль запароть. Каждый раз цербера ставить на обновление модуля? У БИТа сил не хватит ковырять чужой код и проверять его на совместимость с системой и остальными модулями. ПС: Вот еще сходу один вопрос про обновление модуле, как, несколько поставщиков опять же ?)
43. RustIG 1351 26.06.13 18:22 Сейчас в теме
(22) не согласен, (21) согласен
я думаю если ребята будут делиться кейсами своих "модулей", то получится хорошая база модулей. я например много разных разработок с Инфостарта уже использовал как готовые модули, за качество которое отвечает сообщество :)
11. 1c-intelligence 12771 26.06.13 10:31 Сейчас в теме
(9) AllexSoft, также помним, что будет ЭКОСИСТЕМА.

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

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

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

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

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

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

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

Если модуль Б пишется как дополнение к А, то модуль Б постарается узнать об А как можно больше. Это А может не знать о существовании модуля Б.
invertercant; +1 Ответить
13. MSensey 49 26.06.13 11:07 Сейчас в теме
Как все сложно то.

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

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

>> в название нужно добавить префикс или постфикс, отличающих его от аналогичных.
Зачем предлагать решение, которое не решает проблему?
RustIG; Elisy; +2 Ответить
35. Elisy 948 26.06.13 15:30 Сейчас в теме
(13) MSensey,
Я сам за простоту.

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

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

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

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

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

Проблема уникальности названий от разных разработчиков в рамках одной конфигурации решается. Или вы имеете ввиду какую-то другую проблему?
14. bulpi 215 26.06.13 11:18 Сейчас в теме
"Горе от ума" (с) Грибоедов.
15. Gilev.Vyacheslav 1910 26.06.13 11:53 Сейчас в теме
напоминает: легче свою книжку написать чем прочитать уже написанное...

сколько можно изобретать велосипед
ojiojiowka; investec; wolfsoft; zqzq; Chernik; RustIG; lamelioss; +7 Ответить
17. AllexSoft 26.06.13 11:59 Сейчас в теме
(15) Gilev.Vyacheslav, пока 1С не предложит механизм модульности на уровне платформы это все так и останется поделками
20. frying 21 26.06.13 12:25 Сейчас в теме
(15) Gilev.Vyacheslav,
Вячеслав, мы не знакомы с какими-либо материалами, описывающими попытки сделать модульные решения или описывающими неразрешимые проблемы. Если Вам они известны, можете привести ссылку?
obemgyorik; +1 Ответить
47. Elisy 948 26.06.13 18:52 Сейчас в теме
(15) Gilev.Vyacheslav,
сколько можно изобретать велосипед

Как говорится: "Не боги горшки обжигают". БСП тоже когда-то была "велосипедом". Со временем стала веломобилем.
19. lamelioss 143 26.06.13 12:21 Сейчас в теме
ну в принципе как стартап пойдет, но неудобств в плане разработки все равно много
2 Gilev.Vyacheslav - согласен
26. juntatalor 63 26.06.13 13:03 Сейчас в теме
Серьезных отличий от методологии из БСП 2.1 не заметил. Разве что навороты с иерархией подсистем - логика "зачем" мне ясна, но подход не нравится нагруженностью.
42. RustIG 1351 26.06.13 18:18 Сейчас в теме
(0) кол-во взаимоувязок делает идею сложновоспринимаемой. "только для энтузиастов" :)
50. imm0rtal 14 26.06.13 21:24 Сейчас в теме
На первый взгляд, очередной велосипед
С другой стороны, в 1с давно не хватает модульности, и как вариант решения пойдет
51. hogik 443 26.06.13 22:34 Сейчас в теме
(0)
"Так, например, у разных поставщиков может быть справочник Настройки. Невозможно добавить справочники с одинаковыми наименованиями в одну конфигурацию. Поэтому в название нужно добавить префикс или постфикс, отличающих его от аналогичных."(с)

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

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

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

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

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

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

Думаю, это не предмет всеобщего обсуждения, тем более в этой теме. Условия средние. Более важно, что люди и задачи интересные, специалисты из разных городов, не только из Москвы. Команда сложилась гармонично, это значит, что после проекта останутся друзья. Еще экзотика.
55. vde69 925 27.06.13 09:04 Сейчас в теме
когда я писал свою статью (а вышла она на 15 дней раньше сабжа) я разумеется продумывал описаную у Вас в статье реализацию, это была самая простая идея, заметим что как и мои предложения базой является обьект "подсистема".

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

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

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

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

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

Текущий подход не запрещает сделать такой обмен между модулями сторонним вендорам. Если такой способ будет удобным, все его смогут взять на вооружение. Мы планируем пока организовать шину данных для обмена между одноименными модулями, расположенными в SaaS и интегрированными локально к пользователю.
68. 1c-intelligence 12771 27.06.13 21:11 Сейчас в теме
(62) не стоит слепо игнорировать регламенты, доминирование, унижение и телесные наказания. WalterMort прав: модульность можно обеспечить правилами. Просто никто не пробовал.

Тут все будет зависеть от владельцев экосистемы.
70. Elisy 948 28.06.13 05:16 Сейчас в теме
(68) zaebunga,
(62) не стоит слепо игнорировать регламенты, доминирование, унижение и телесные наказания. WalterMort прав: модульность можно обеспечить правилами. Просто никто не пробовал.
Тут все будет зависеть от владельцев экосистемы.

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

Внешние компоненты Native API не несут функциональности по интерфейсу. Можно рассмотреть вариант интеграции по html. Например, формирование рабочего стола при загрузке 1С из разных модулей.
74. Elisy 948 01.07.13 09:33 Сейчас в теме
По ходу реализации возникла проблема вывода из модулей форм АРМ в рабочую область начальной страницы
Более подробно о проблеме можно почитать в ветке форума.
Как программно управлять начальной страницей?
76. krv2k 375 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 948 10.07.13 20:12 Сейчас в теме
Спасибо всем за ваши ценные комментарии.
Сейчас в нашей системе несколько модулей: Базовые справочники, Задачи, Управление клиентской базой, База знаний
Разрабатывается центральный для всех модуль Процессная шина.
Эти несколько модулей позволяют сформулировать требования к оформлению модулей. Сейчас известно, что каждый модуль будет сопровождаться функциональной опцией для всех своих элементов. Подсистемы модулей будут помещены в подсистему Модули. Будут интерфейсные подсистемы, расположенные в корне подсистем, чтобы можно было их показывать в панели разделов.
От хранения списка модулей в параметрах сеанса, скорее всего, придется отказаться.
80. Evgen.Ponomarenko 567 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, не хотите написать статью, с примерами и скриншотами ? тут всем было бы интересно увидеть реально функционирующую модульную систему
86. Evgen.Ponomarenko 567 11.07.13 22:20 Сейчас в теме
(81) AllexSoft,

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

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

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

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

Система разрабатывалась силами 3-х человек: один идеолог, один разработчик + один специалист технической поддержки.
Когда пришло осознание новизны автор концепции издал книгу "Управление реальным предприятием. Новая концепция."
автор - Кустов Михаил Геннадиевич.
В книге описана простым языком математика, которая легла в основу прикладного конструктора модулей.
Так, что всему свое время )))) будут и примеры, будут и скриншоты )))))
88. AllexSoft 14.07.13 23:34 Сейчас в теме
(86) Evgen.Ponomarenko, ждем с нетерпением
82. fgremlin 11.07.13 09:30 Сейчас в теме
(80) Evgen.Ponomarenko,

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

Многоуважаемый Михаил, я не понял вашего вопроса - уточните его плиззз.
89. yackimoff 06.08.13 22:17 Сейчас в теме
Несмотря на то, что 1С выпустила БСП, как шаг к модульности приложений, хотелось бы видеть несколько альтернативных подходов.

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

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

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

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

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

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

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

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

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

Понятно, что модульность снижается, однако, тут уже вопрос приоритетов; о ком вы больше заботитесь: о пользователе или о разработчике.
90. Elisy 948 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 948 07.08.13 13:11 Сейчас в теме
Я говорил, скорее, не про саму БСП, сколько про эволюционирующий там подход к интеграции различных подсистем.
Конечно, возможно, что ни в самой БСП, ни в её техниках нет всей нужной функциональности. Но зачем подменять ту, что есть?

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

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

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

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

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

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

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

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

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

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

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