gifts2017

Программирование интерфейсов в 1С или паттерн MVC для 1С

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

С какими трудностями можно столкнуться при разработке интерфейса? Одно дело - Вы разработчик системы с нуля, и другое - чего у меня случалось чаще - Вы дорабатываете интерфейс типовой конфигурации, в которой от типового функционала осталось только название. И вот я в очередной раз смотрю на творение n-го количества программистов, поработавших в коде до меня: ни тебе системного подхода, ни качества кода, ни оформления (как этот  код работает - никто не знает). А как это работает? На поверку оказывается, что, в общем и целом - работает. Однако при невыясненных обстоятельствах иногда становится недоступным нужный реквизит, или тип реквизита не тот, или вообще часть реквизитов не видна. А еще, почему то, при простом открытии формы на экран, в документе изменяются значения!?

Введение

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

С какими трудностями можно столкнуться при разработке интерфейса? Одно дело - Вы разработчик системы с нуля, и другое - чего у меня случалось чаще - Вы дорабатываете интерфейс типовой конфигурации, в которой от типового функционала осталось только название. И вот я в очередной раз смотрю на творение n-го количества программистов, поработавших в коде до меня: ни тебе системного подхода, ни качества кода, ни оформления (как этот  код работает - никто не знает). А как это работает? На поверку оказывается, что, в общем и целом - работает. Однако при невыясненных обстоятельствах иногда становится недоступным нужный реквизит, или тип реквизита не тот, или вообще часть реквизитов не видна. А еще, почему то, при простом открытии формы на экран, в документе изменяются значения!?

И вот теперь этот документ нужно доработать. Всего лишь добавить один реквизитик. Как только Вы это сделали - все, теперь проклятие документа падет на Вас! А как Вы хотели? С документом раньше работали и все было - ОК, а тут после Вашей доработки вдруг полезли косяки... Особенно интересно, когда такие претензии выдвигают уже Вам, хотя Вы всего лишь добавили один реквизит.

Вообщем у меня есть один подход. Я его выработал и успешно применяю уже много лет. В этой статье я хочу поделиться своим опытом, и может быть этот опыт поможет Вам лучше осознать свою деятельность и не быть одним из тех n-ых программеров, которые просто добавляют реквизиты и требуют деньги за свою работу (я не против, любая работа должна быть оплачена, но не любая работа достойна достойной оплаты). Возможно, я здесь задел достаточно острый вопрос качества кода, ресурсов, бюджета и т.д. Но не буду отвлекаться.

MVC

Немного теории на тему. Существует весьма известный шаблон проектирования интерфейса - MVC  (Model View Control) 1)2). Шаблон состоит из трех компонентов: модель данных (Model), пользовательский интерфейс (View), управляющая логика (Control). Реализация каждого из компонентов делается отдельно, а их сочетание позволяет пользователю работать с данными через интерфейс. Такая модель реализации позволяет не только разделять работу по проектированию собственно интерфейса (View), управляющей логики (Control) и функциональной логики приложения (Model), но и создавать различные сочетания этих трех компонентов.

Фактически в 1С можно реализовать независимо два компонента модели: Document-View и Model 3).

 

Рисунок 1. Иллюстрация компонентов модели MVC. Источник: http://www.dossier-andreas.net/software_architecture/mvc.html

Реализация идеи MVC на 1С

Пример реализации

Перейду к конкретным примерам. Возьмем объект метаданных «Документ». Так в роли Document-View будем считать реализацию пользовательского интерфейса в форме документа. В реализации пользовательского интерфейса 1С для документа могут выступать: форма списка, форма выбора, форма документа, специальная форма ввода и т.д. Вся управляющая логика может быть представлена процедурами модуля формы документа. Функциональная логика (Model) реализована в модуле документа.

Суть метода MVC в реализации на 1С

Использование подхода MVC для 1С заключается в разделении реализации формы (далее интерфейс  я буду по 1С-овски просто называть формой) и объекта. Все события формы  должны вызывать соответствующие процедуры объекта, изменяющие данные. Вся обработка данных должна быть в объекте (это так называемая бизнес-логика). При этом изменение одних данных может влиять на другие и наоборот  - одни данные могут зависеть от других. Такой подход позволяет использовать одни и те же процедуры обработки данных объекта как из кода (из бизнес-логики), так и из интерфейса (из различных форм). Понимаете о чем я?

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

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

Здесь есть один подвох. Не всегда зависимости распространяются строго в одном направлении. Иногда могут возникать "обратные петли" зависимостей. Для обеспечения устойчивого кода таких зависимостей необходимо избегать. В случае возникновения петель нужно просто не добавлять вызов процедуры зависимых данных, а реализовывать обработку данных непосредственно на месте вызова текущей процедуры бизнес-логики.

Разделение процедур отображения и бизнес-логики

События формы и их обработка

В общем случае связь с данными в форме осуществляется через её реквизиты. Отношения данных между собой можно описать связью в реквизитах формы по владельцу и по типу. Однако указание только таких отношений недостаточно. Часто на практике встречаются зависимости заполнения одних реквизитов от изменения других. Графически такие зависимости можно представить в виде графа зависимостей.

Пример: при изменении договора контрагента необходимо установить валюту взаиморасчетов по договору, получить курс на дату, пересчитать валютную сумму, заполнить счет взаиморасчетов.

 

Рисунок 2. Визуальное представление распространения зависимостей реквизитов формы

 

 

Рисунок 3. Диаграмма зависимостей реквизитов

На рисунке 2 показана циклическая зависимость для реквизитов «Курс» и «Сумма (вал)» - это так называемые петли зависимостей. Реализация «петлей зависимости» в алгоритме выливается в бесконечный цикл и, как следствие, –  в зависание или падение приложения. Как правило, ошибки такого рода быстро выясняются на этапе тестирования и код не зацикливается. На уровне бизнес-логики при возникновении циклических зависимостей необходимо выполнять обработку данных без вызова обработчиков зависимых данных (можно такую функциональность вынести в отдельную общую процедуру и вызывать из взаимно-зависимых процедур обработки).

Отображение формы

Все действия по формированию отображения формы я предлагаю выносить в отдельную процедуру «УправлениеВидимостьюДоступностью». Путь эта процедура будет в каждой форме, тогда при событиях изменения данных в форме обработчик события должен выполнить вызов этой процедуры в конце выполнения. В этой процедуре осуществляется управление видимостью и доступностью реквизитов, закладок, установка доступных типов реквизитов, настройка визуальных свойств, меню, списков выбора и т.д. Вызов процедуры «УправлениеВидимостьюДоступностью» следует также использовать в событиях формы: ПриОткрытии, ПриИзменении (см. пример в Листинг 1).

Важно, что в процедуре «УправлениеВидимостьюДоступностью» ни в коем случае не должны изменяться сами данные!

Изменения данных (бизнес-логика)

Введем разделение процедур обработки данных формы: процедуры изменения данных и процедуры обработки событий формы.

Процедура обработки события – процедура, вызываемая по событию из формы

Процедура изменения данных – процедура бизнес-логики, располагаемая в модуле объекта

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

Ниже приведены примеры кода (см. Листинг 1, Листинг 2) для интерфейсной части и бизнес-логики. Обратите внимание, что код бизнес-логики реализован в модуле объекта и с использованием ключевого слова Экспорт, т.к. иначе процедуры модуля объекта не будут доступны в модуле формы.

Соглашения о наименованиях процедур

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

Модель

Наименование процедуры

Комментарий

Процедуры модуля формы (паттерн Document-View)

УстановитьВидимостьДоступность

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

ИмяРеквизитаПриИзменении

процедура события реквизита формы ПриИзменении

Процедуры бизнес-логики (паттерн Model)

ПриИзмененииИмяРеквизита

процедура события изменения данных объекта. Процедура относится к реализации бизнес-логики и располагается в модуле объекта.

Вывод

В этой статье был рассмотрен паттерн проектирования MVC в приложении 1С. Изначально я не планировал рассмотрение именно MVC, основной мой мотив был в подаче метода разработки надежных интерфейсов 1С. Однако программисты 1С – это все же практики программирования и каждого из Вас есть свой подход. Этот подход Ваш и он также работает. Теория же нам необходима, когда мы упираемся в ограничения: обеспечение скорости, надежности разработки, стоимость сопровождения. Надеюсь, предложенный подход в статье оказался для Вас полезным, а теоретическое обоснование интересным.

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

Итак, основные тезисы:

  • ·         Необходимо разделять процедуры интерфейса и бизнес-логики
  • ·         Процедуры интерфейса располагаются в модуле формы
  • ·         Процедуры бизнес-логики должны находиться в модуле объекта. Процедуры, вызываемые из формы используют ключевое слово Экспорт
  • ·         Зависимости реализуются через каскадные вызовы зависимых процедур. Для предотвращения циклических вызовов необходимо реализовывать функциональность без вызова зависимых процедур.

 

Листинг 1. Пример реализации модели Document-View в модуле формы

 

//  УстановитьВидимостьДоступность
//  Процедура настраивает вид формы: видимость, доступность, типы значений реквизитов, списки выбора, заголовки
//
Процедура УстановитьВидимостьДоступность()

   
// Вывести в заголовке формы вид операции и статус документа (новый, не проведен, проведен)
    //
   
РаботаСДиалогами.УстановитьЗаголовокФормыДокумента(Строка(ВидОперации) , ЭтотОбъект, ЭтаФорма);

   
//  Установка доступности реквизитов
   
...
   
ЭтоВалютаРубли = Валюта = мВалютаРегламентированногоУчета;
   
ЭлементыФормы.Курс        .Доступность = Не ЭтоВалютаРубли;
   
ЭлементыФормы.СуммаВал    .Доступность = Не ЭтоВалютаРубли;
   
ЭлементыФормы.Кратность   .Доступность = Не ЭтоВалютаРубли;
    ...
КонецПроцедуры

...

// Процедура - обработчик события "ПриОткрытии" формы.
//
Процедура ПриОткрытии()
    ...
   
УстановитьВидимостьДоступность();
КонецПроцедуры

...

/////////////////////////////////////////////////////////////////////////////////////////
//  События формы ПриИзменении
//

Процедура СуммаПриИзменении(Элемент)
   
//  Вызов процедур модуля
   
ПриИзмененииКурса(Валюта    , Курс   , Кратность    , СуммаВал);
   
//  Вызов процедуры отображения формы
   
УстановитьВидимостьДоступность();
КонецПроцедуры

Процедура
КонтрагентПриИзменении(Элемент)
   
//  Вызов процедур модуля
   
ПриИзмененииКонтрагента(Контрагент,
       
ДоговорКонтрагента, ВидДоговора, ВидРасчетов,
       
Счет, ЭтоСчетАванса(""), Валюта, Курс, Кратность, СуммаВал);
   
//  Вызов процедуры отображения формы
   
УстановитьВидимостьДоступность();
КонецПроцедуры

Процедура
ДоговорКонтрагентаПриИзменении(Элемент)
   
//  Вызов процедур модуля
   
ПриИзмененииДоговораКонтрагента(Контрагент,
       
ДоговорКонтрагента, ВидДоговора, ВидРасчетов,
       
Счет, ЭтоСчетАванса(""), Валюта, Курс, Кратность, СуммаВал);
   
//  Вызов процедуры отображения формы
   
УстановитьВидимостьДоступность();
КонецПроцедуры

Процедура
ВалютаПриИзменении(Элемент)
   
//  Вызов процедур модуля
   
КурсКратность       = ОбщегоНазначения.ПолучитьКурсВалюты(Валюта, Дата);
   
Курс        = КурсКратность.Курс;
   
Кратность   = КурсКратность.Кратность;
   
ПриИзмененииКурса(Валюта, Курс, Кратность, СуммаВал);
   
//  Вызов процедуры отображения формы
   
УстановитьВидимостьДоступность();
КонецПроцедуры

Процедура
КурсПриИзменении(Элемент)
   
//  Вызов процедур модуля
   
ПриИзмененииКурса(Валюта, Курс, Кратность, СуммаВал);
   
//  Вызов процедуры отображения формы
   
УстановитьВидимостьДоступность();
КонецПроцедуры

Процедура
СуммаВалПриИзменении(Элемент)
   
//  Вызов процедур модуля
   
ПриИзмененииВалСуммы(СуммаВал, Курс, Кратность, СуммаВал);
   
//  Вызов процедуры отображения формы
   
УстановитьВидимостьДоступность();
КонецПроцедуры

 

Листинг 2. Пример реализации модели бизнес-логики (Model). Процедуры бизнес-логики, вызываемые из модуля формы.

 

/////////////////////////////////////////////////////////////////////////////////////////
//
//  Процедуры ПриИзменении
//
/////////////////////////////////////////////////////////////////////////////////////////

Процедура ПриИзмененииВалСуммы(СуммаВал, Курс, Кратность, СуммаВалютная) Экспорт

    Если
СуммаВалютная = 0 или Кратность = 0 Тогда
        Возврат;
    КонецЕсли;
   
//  Каскадный вызов процедур зависимых реквизитов отсутствует.
    //  Значение реквизита изменяется непосредственно:
   
Курс = Сумма / (СуммаВалютная * Кратность);

КонецПроцедуры

Процедура
ПриИзмененииКурса(Валюта, Курс, Кратность, СуммаВалютная) Экспорт
    Если Не
ЗначениеЗаполнено(Валюта) Тогда
        Возврат;
    КонецЕсли;
   
//  Каскадный вызов процедур зависимых реквизитов отсутствует.
    //  Значение реквизита изменяется непосредственно:
   
СуммаВалютная = ОбщегоНазначения.ПересчитатьИзВалютыВВалюту(Сумма,
                       
мВалютаРегламентированногоУчета, Валюта, 1, Курс, 1, Кратность);

КонецПроцедуры

Процедура
ПриИзмененииКонтрагента(Контрагент, ДоговорКонтрагента, ВидДоговора, ВидРасчетов, Счет, ЭтоСчетАванса, Валюта, Курс, Кратность, СуммаВалютная) Экспорт
   
//  Проверка на зависимость от реквизитов верхнего уровня
    //
   
Если Не ЗначениеЗаполнено(Контрагент) Тогда
        Возврат;
    КонецЕсли;

    Если Не
ЗначениеЗаполнено(ДоговорКонтрагента) И ЗначениеЗаполнено(Контрагент.ОсновнойДоговорКонтрагента) Тогда
       
ДоговорКонтрагента = Контрагент.ОсновнойДоговорКонтрагента;
    КонецЕсли;
   
//  Каскадный вызов процедур зависимых реквизитов
    //
   
ПриИзмененииДоговораКонтрагента(Контрагент, ДоговорКонтрагента, ВидДоговора, ВидРасчетов, Счет, ЭтоСчетАванса, Валюта, Курс, Кратность, СуммаВалютная);
КонецПроцедуры

Процедура
ПриИзмененииДоговораКонтрагента(Контрагент, ДоговорКонтрагента, ВидДоговора, ВидРасчетов, Счет, ЭтоСчетАванса, Валюта, Курс, Кратность, СуммаВалютная) Экспорт
   
//  Проверка на зависимость от реквизитов верхнего уровня
    //
   
Если Не ЗначениеЗаполнено(ДоговорКонтрагента) Тогда
        Возврат;
    КонецЕсли;

    Если Не
ЗначениеЗаполнено(Контрагент) ИЛИ ДоговорКонтрагента.Владелец<>Контрагент Тогда
       
ДоговорКонтрагента = "";
        Возврат;
    КонецЕсли;
    ...
   
//  Каскадный вызов процедур зависимых реквизитов
    //
   
ПриИзмененииКурса(Валюта, Курс, Кратность, СуммаВалютная);

КонецПроцедуры

Список источников

  1. http://ru.wikipedia.org/wiki/Model-View-Controller
  2. http://www.rsdn.ru/article/patterns/generic-mvc.xml
  3. http://www.rsdn.ru/article/patterns/modelviewpresenter.xml

 

См. также

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

Комментарии

1. Саня Офигенски (AlexProg) 09.10.12 16:53
Статья хорошая, но через чур умная для 1С.
kalyaka, мы же не можем в рамках 1С реализовать инкапсуляцию или абстракцию данных, поэтому каждый такой слой будет снабжен большим количеством структурных сервисных механизмов, либо придется делать огромное количество слоев (как в типовых конфигурациях 1С), для того, чтобы реализовать достаточно универсальную модульную структуру интерфейсного кода. Поэтому рассматривать MVC для не объектного ориентированного подхода считаю не логичным. Надеюсь понятно написал.
2. Игорь Воронкин (Воронкин) 09.10.12 17:05
(1) AlexProg.
Согласен с первым комментарием. А я пишу интерфейсы, не имея понятия о MVC.
3. ВладАн (ВладАн) 10.10.12 03:15
ни тебе системного подхода, ни качества кода, ни оформления

Интересно как часто клиенты столкнувшись с ошибками в типовых конфигураций 1С рассуждают об цитате.

ЗЫ: Рассуждения о большом, теплом и пушистом плавно перетекающиеся в утопию по моему мнению.
quebracho; papami; +2 Ответить 1
4. Андрей Казанцев (ander_) 10.10.12 07:49
Поддержу автора. Следить за порядком в коде нужно. MVC... ну почему бы и нет. Свою "жизнеспособность" он неоднократно доказал.
(1) AlexProg
...через чур умная для 1С.

Давайте уж тогда называть вещи своими именами. Не для 1с, а для некоторых 1с-ников.

(2) Воронкин
...А я пишу интерфейсы, не имея понятия о MVC.

Это повод для гордости?

(3) ВладАн
Вопрос скорее несколько о другом. Об ошибках привнесенных "на местах", в дополнение и вместо "типовых".
5. Игорь Антонов (dalgaso2010) 10.10.12 09:14
Плюсанул. Сам доволен MVC паттерном и тоже стараюсь применять его в разработке конфигураций под платформу 1С-предприятий. Впервые столкнулся с MVC (а потом HMVC) в PHP и можно сказать влюбился в него. Правда MVC тоже не панацея.
6. Андрей Овсянкин (Evil Beaver) 10.10.12 09:48
MVC плохо применима в 1С, см. все предыдущие комментарии. Получится в лучшем случае гибрид ежа и ужа, который понять не проще, чем труд "n-ного числа программистов", не применяющих MVC.
7. Саня Офигенски (AlexProg) 10.10.12 10:44
(4) ander_, и автор. Вот Вы дали ссылку на википедию, сами интересно читали эту статью?


Наиболее частые ошибки

Начинающие программисты (особенно в веб-программировании, где аббревиатура MVC стала популярна) очень часто трактуют архитектурную модель MVC как пассивную модель MVC. В этом случае модель выступает исключительно совокупностью функций для доступа к данным, а контроллер содержит бизнес-логику. В результате код моделей по факту является средством получения данных из СУБД, а контроллер представляет собой типичный модуль, наполненный бизнес-логикой, или скрипт в терминологии веб-программирования. В результате такого понимания MVC разработчики стали писать код, который Pádraic Brady, известный в кругах сообщества Zend Framework, охарактеризовал как ТТУК — «Толстые тупые уродливые контроллеры» (Fat Stupid Ugly Controllers)[6]:

Среднестатистический ТТУК получал данные из БД (используя уровень абстракции базы данных, делая вид, что это модель) или манипулировал, валидировал, записывал, а также передавал данные в вид. Такой подход стал очень популярен потому, что использование таких контроллеров похоже на классическую практику использования отдельного php-файла для каждой страницы приложения.

Но в объектно-ориентированном программировании используется активная модель MVC, где модель — это не только совокупность кода доступа к данным и СУБД, а вся бизнес-логика. В свою очередь, контроллеры представляют собой лишь элементы системы, в чьи непосредственные обязанности входит приём данных из запроса и передача их другим элементам системы. Только в этом случае контроллер становится «тонким» и выполняет исключительно функцию связующего звена (glue layer) между отдельными компонентами системы.


Что-то не понятно? В .NET мы не работаем с визуализаторами, а с объектами, которые инкапсулируют достаточно методов, которые могут реализовать свой слой взаимодействия.

1С сам по себе готовый шаблон и среда проектирования. И пришивание других шаблонов это обычное умничанье. Не называйте прилежность и аккуратность - правильным проектированием. Это в корне не верное понимание. Порядок в коде, и удобные универсальные функции не имееют никакого отношения к системе - Модель, Представление, Контроллер. 1С тут всё делает за нас изначально. В языке невозможно расширить метод или объект. Невозможно представить форму как объект, даже тип данных в базе данных нельзя хранить. Поэтому и появляются уродства, как "планы видов", которые позволяют делать расширенные абстракции данных. Про интерфейс вообще забудьте. У Вас половина данных имеют связывание непосредственно с формой, давая доступ только для чтения. И манипулировать ими Вы можете только считав эти данные с формы (в 8.2 еще больше). Хотите парадигму - вот вам построитель, СКД и хватит :)
xzorkiix; vlasin; bulpi; kuntashov; pumbaE; +5 Ответить 2
8. Андрей Казанцев (ander_) 10.10.12 11:00
(7) AlexProg, :) читал. По-большому счету соглашусь. То что можно сделать в 1с это не столько само MVC в лучших его появлениях, сколько позаимствованный из него образ мышления, позволяющий "отделять мух от котлет".
Но ценности MVC, и полезности изучения этого паттерна (впрочем как и многих других) 1с-никами, это не уменьшает ;)

ЗЫ: в принципе автор на примере показал что он имел ввиду. Идея понятна, откуда позаимствовано, и чем навеяно тоже. Грубо говоря это MVC в том виде, в котором его позволяет реализовать данная среда. Вот.
9. Саня Офигенски (AlexProg) 10.10.12 11:22
(8) ander_, Ну так нам не долго до того, что 1С будут называть объектно-ориентированным языком :) 1Сников будут ставить в один ряд с нормальными программистами. Нет, пока этого не будет. Потому что 1С начисто искажает все современные и адекватные системы разработки.
Конечно со временем появляются "общие модули", "подписки на события", "команды" которые дают пространство для полета творческой мысли, немного расширяя кандовость творения Нуралиева и двух бутылок водки. Но, еще очень и очень далеко. Мышление сильно отличается, соответственно сильно уменьшается вариативность самого мышления. И расширять познания в другой области это не поможет, информация и умение - это как небо и земля. Думаю 1С ниасилит что-то действительно красивое.
10. Nike K (Nkolp) 10.10.12 12:55
Oh, Mein Gott!! Эта тема периодически поднимается и волнует некоторые умы ...:) Я 17 лет назад перешел с C++ на 1C - тогда вышла торговля 7.0. И это был мой выбор, о котором я не жалею. А тогда мне просто надо было зарабатывать деньги, и я благодарен братьям Нуралиевым за то, что они дали возможность тысячам наших программистов работать по специальности, а не торговать в ларьках. Это тогда .... А теперь, проработав 10 лет методистом по конфигурированию скажу - 1) недостаток базового образования - это беда большинства программистов 1С,2) в системе ЦСО 1С нет ни одного курса обучающего основам программирования - наверное потому, что этому бизнесу не нужны программисты широкого профиля, которые могут не только 1С, немного XML и то, что связано с обменом данными ... и 3)1С ни в коем случае нельзя позиционировать, как ПО для начального обучения программированию - это чисто прикладное ПО со своей областью применения.
11. Nike K (Nkolp) 10.10.12 13:03
А за статью спасибо - хорошая мысль: надо обратить на это внимание, на ближайшем курсе :)
12. qwe qwerty (quebracho) 10.10.12 13:04
Статья для новичков, но они читать не будут, т.к. слишком много букв да еще и расплывчато как-то. Надо было просто и понятно писать, вроде:
"Не вари козленка в молоке матери его" :) Автор, без обид.
13. absolutblohin (absolutblohin) 10.10.12 13:04
Минусовать бы такие статьи.
1. Для управляемых форм каждый вызов метода объекта вызывает сервер (на клиенте объекта просто нет). При Сумма = Количество * Цена, вызывать сервер нет смысла, все данные уже есть на форме. Зачем делать аналогичный метод для объекта? Чтоб гордится собой? У вас оплата за количество строк кода?
2. По той же причине вызывать при каждом действии установку видимости/доступности. Вполне достаточно только там где влияет.
3. В (7) все правильно сказано. Не надо притягивать за уши только что изученные методики в 1с, не надо новичкам пудрить мозги, все это только усложняет код, а в данном случае еще ведет к постоянному дерганью сервера. Не опытные программисты часто забывают что они в лесу базе не одни работают, и если 1000 человек начнет дергать сервер по причине что программист почитал про MVC...
4. Автору необходимо сначала лучше изучить 1с и клиент-серверное программирование, а потом клепать статьи. В 8.2 программистов "принудительно" перевели на разделение бизнес логики и интерфейса.

Я, в общем, не сомневаюсь, что автор знает 1с, и прошу прощения за резкий тон, но тогда тем более не понятна технологическая отсталость, и заидеалезированность статьи.
14. Роман (Raminus) 10.10.12 13:13
В одном я с автором согласен, порядок должен быть :)
15. Саня Офигенски (AlexProg) 10.10.12 13:36
(13) absolutblohin, да зачем минусовать :) Надо чтобы народ узнавал больше и пробовал больше, и до него начинало доходить, что 1С это не супер пупер, не абсолютная утопия, а лишь незначительный продукт, который уступает абсолютно всем и во всём. Его достоинство лишь в том, что агрессивным способом завоевал рынок в стране и вытеснил другие разработки. Пора нам уже вылезать из деревни, где нас 1С активно держит.

(10) Nkolp, Да, тогда программист 1С получал в два раза больше чем С++ник. А сейчас нет. Более того, я уже писал тут где-то, возможностей у него в разы меньше для развития, тупеет он от этой системы, и востребован слабо. Не готов к приходу новых систем, и чрезвычайно консервативен в своих "пристрастиях" из-за этого. Я очень сильно жалею, что стал программировать в 1С. Более того сама 1С тормозит рынок ИТ в стране. Если бы была нормальная конкуренция, инвариантность в подходах, платформах, средах, т.е. как сейчас на западе и в азии, то качество, охват, и соответственно доходы от таких разработок были бы в разы выше. Это нужно же понимать. А сейчас в самой фирме 1С программисты считаются овном, и это понимание они навязывают уже 10 лет по всей стране. И получают ответную реакцию - профессионалы уходят, как можно быстрей из 1С, а молодняк из года в год проходит все по тем же багам, граблям, и потом на последнем дыхании пытается вырваться из этого кошмара.
16. absolutblohin (absolutblohin) 10.10.12 14:08
(15) AlexProg, эээ... ну с этим я не согласен, для своих целей 1с абсолютный лидер, я считаю. Конфигурации подкачали, конечно, а платформа хороша. Ей, правда, развиваться и развиваться... 1с это продукт компромисса, и этот компромисс вполне удачный. Но как и в любом компромиссе кто-то будет чем-то недоволен

(14) Raminus, порядок то должен быть, но не из области - "все жители моего графства должны иметь одинаковый рост".
CyberCerber; quebracho; +2 Ответить 1
17. Саня Офигенски (AlexProg) 10.10.12 14:15
(16) absolutblohin, можно узнать, с чем вы сравниваете?
За 20 лет то можно было бы "развить". Я конеш понимаю, в стенфордах или мти не учились, но элементарную совесть можно было бы поиметь :)
18. absolutblohin (absolutblohin) 10.10.12 14:19
(17) AlexProg, сравниваю с сап и дейнамикс, правда сравниваю по удобству разработки, по скорости тут кхмх... И да, совести у фирмы 1с мало.
19. Саня Офигенски (AlexProg) 10.10.12 14:30
(18) absolutblohin, хорошо, что не с access :) САП конечно старичок еще тот. В мире огромная линейка продуктов. Найдите ссылку на статью тут "Почему не хватает 1Сников?" (или как-то так), я там вайн породил на похожую тему, я там давал ссылки. Причем все свои идеи 1Сцы в чистом виде воруют у таких продуктов, а как раз платформа не дает реализовать их в чистом виде. Получается продукт: 1СКомпромис, или очередная горба, которую должна переварить вся страна.
20. absolutblohin (absolutblohin) 10.10.12 14:53
(19) AlexProg, ну ворует... самсунг тоже у эпла дизайн своровал :-)
При всех недостатках 1с, можно сказать что они создали на практике предметно-ориентированное, и в этом есть несомненная заслуга. По вашей ссылке, в общем правильно вопрос рассмотрен... но какие выводы делать? Либо менять платформу, либо не менять. Тут каждый сам себе хозяин-барин. Кто 12 лет назад перешел на 1с (я кстати тоже), сам несет ответственность за свой поступок, как бы нас 1с не кидала. У меня периодически возникает беспокойство по поводу что в 1с слишком врос, но пока как-то удается себя успокоить...
21. Саня Офигенски (AlexProg) 10.10.12 15:03
(20) absolutblohin, да сейчас посмотрим.
Фрилансеров официально утвердят. Роль франчайзи будет потихоньку спадать на нет. Не скоро конечно, но неумолимо. 1С продажи все сильней подтягивает под себя. Засертифицировать и затиранить фрилансеров у 1С не получится, как она это делала с франчами, ибо тупо нечем брать. Сертификаты и так все клеят сами знаете куда. А вот тут уже мы сами будем определять развитие отрасли. 1С станет послушным вендором, а не всевластным тираном. Плюс развитие NET и подобных технологий, переориентированность на облака, где 1С далеко не впереди, даже в скупе с битриксом. Поживем увидим :) А беспокойство я лично убираю постоянным изучением новых технологий, чего всем Вам и советую. Ибо считаю 1С технологическим трупом.
22. absolutblohin (absolutblohin) 10.10.12 15:15
(21) AlexProg, для франчей ниша всегда останется. Большой проект фрилансеру тупо никто не даст... Опять же, фрилансер когда перерос себя на этом поприще, что делает? Правильно, создает свою фирму-франчайзи. Такой вот круговорот фрилансеров в природе.
23. Саня Офигенски (AlexProg) 10.10.12 15:23
(22) absolutblohin, Хи хи. Почему не даст. Я вот уже несколько больших заводов, крупных дистрибьютерских сетей в однорепье сделал. Фирмы открывают, но совсем не обязательно 1С франчайзи. Никому сейчас столько гемора, который дает приставка "1С" не нужно. Оплату, поставку, все решаем. Официальный статус фрилансера дает много преимуществ, которых не было раньше. Ждемс :)

Еще можно добавить, что наконец-то происходит пересмотр в умах людей подхода к аутсорсингу. Где на первое место выходит не "статус", а квалификация и портфолио. Где финансовый доход полноценно получает не тот, кто в теме, а тот, кто выполняет непосредственную работу. А команду можно и из нескольких фрилансеров собрать, как и проект, было бы желание, повод и средства найдутся. А на этом поле 1С это лишь метафизический материал, но ни как не диктатор, определяющий правила игры. Вообщем-то в англии например, уже лет 30 так.
24. absolutblohin (absolutblohin) 10.10.12 15:32
(23) AlexProg, а на сколько больших заводов? Максимально большой завод что мне удалось получить это 700 человек, в простонародье называется средний. А вот для больших заводов попадаются такие условия тендера что у франча в 300 человек не хватает оборотов. Не иначе такие условия объявляют, чтоб кроме Раруса никто не удовлетворял.
25. Саня Офигенски (AlexProg) 10.10.12 15:38
(24) absolutblohin, да откуда эти сказки. После Раруса обычно приходится долго и упорно восстанавливать учет. Это наверно сам Рарус и распространяет эти сплетни :)
Мои примеры: Завод 7500 тел, завод 3500 тел, завод 3200 тел, сеть розничных магазинов 150 шт по россии, сеть розничных магазинов по москве и области 80 шт, дистрибьюторская сеть 20 000 наименований, контроль 8000 клиентов, и т.д и т.п. (это далеко не все за 12 лет) Не везде прям в однорепье, но почти :) Вот о чем я и говорю, Россия - дикая страна. Расскажи это где-нить в США, примут за вруна или психа.

Да! Вот как в тему статьи еще попал! Очень очень часто, именно из-за отсутствия паттернов проективрования, паттернов программирования, объектно-ориентированного подхода, общей технологии программирования так и получается, что один программист делает даже лучше, чем целая команда. Сколько я встречал заточенных конфигураций, ошибки в основном там, где "приглашенный человек", "замена основного программиста", "команда" и т.д. Деревня, е-мае. И дело не в людях, или в обучении. А именно в изначально кривой платформе.
26. absolutblohin (absolutblohin) 10.10.12 16:01
(25) AlexProg,
это не сказки, мне приходилось с этим сталкиваться

Завод 7500 тел, завод 3500 тел, завод 3200 тел, сеть розничных магазинов 150 шт

что же, остается только поздравить вас с заработанной репутацией.
программист делает даже лучше, чем целая команда

тут может быть много причин. Я тоже могу сделать лучше чем команда (почти шутка), но вряд ли этот факт дискредитирует идею команды.
Проблема, все таки не в платформе, а в традиции, выучив как ходят фигуры, считать что умеешь играть в шахматы. Сколько людей изучали стандарты разработки с диска ИТС? Среди моих знакомых только я.
27. Саня Офигенски (AlexProg) 10.10.12 16:26
(26) absolutblohin, вот вникните в мою мысль: Как учится человек? Родители думают, что говоря ребенку, как надо жить, он научится. Ребенок же копирует и подражает поведению родителей, потому что он видит связь действия и результата. В итоге - жмуть.

В программировании все точно так-же. Программировать учатся не по учебнику, видео или статье. Программировать учатся по кодам, реализации и результатам. У русского программиста к тому-же абсолютно отсутствует база и культура. Да, конечно через 2-5 лет у человека включается осознание, и появляются иные связи, тогда программист может совершенствоваться и улучшать качество.

А платформа 1С никаким образом не вмешивается в данный "танец природы". Начиная с однообразия оператора присваивания и оператора сравнения, заканчивая мешаниной типов данных в запросах и понимании объекта. (Откуда и появляются такие вот статьи в топикстартере). Шаблон, по которому должно выстраиваться правильное мышление, наглухо разрушен. И правильно, писали его же точно такие же программисты-самоучки, на коленках в обнимку с бутылкой водки. Тут всё логично. Нажмите Ctrl+F1 на каком-нибудь универсальном методе в коде 1С, и Вы сразу поймете отношение разработчиков к потребителям продукта. И таких мелочей сотни в 1С, они никуда не делись еще со времен 7.5. И так будет и дальше, потому что в 1С гнилая голова.
28. absolutblohin (absolutblohin) 10.10.12 16:32
(27) AlexProg, про воспитание и голову это все правда. Тут я со всем согласен.
А
Начиная с однообразия оператора присваивания и оператора сравнения
это дело вкуса.
Хотя мне было ржачно когда первый раз увидел:
УсловиеИстинно = КакаяНибудьПеременная = ЕщеКакаяНибудь;

Я иногда веселюсь используя такое в коде.
29. Саня Офигенски (AlexProg) 10.10.12 16:41
(28) absolutblohin,
УсловиеИстинно = КакаяНибудьПеременная = АВоощеНадоПроверить(ЕщеКакаяНибудь = КакаяНибудьПеременная);
30. Dimon (klel) 10.10.12 20:28
Интересная статья =) + за старания
31. Nike K (Nkolp) 10.10.12 23:25
(15)Собственно поэтому я и ушел на методическую работу, Хотя периодически веду проекты. Проработав столько лет с 1С, кажется что я другого ничего и не умею: приходится себя переубеждать. С absolutblohin согласен, что учетные задачи платформа решает хорошо. А Конфигурации стали громоздкими, потому что пытаются быть универсальными.
32. kiril lipatov (kilokilo) 11.10.12 01:14
(0), (1) AlexProg,

Тут была статья про MVC у kote вместе с иллюстрирующей конфигурацией - хотелось, но не могу найти.. У кого нибудь сохранилось? Вот там разделение кода, по моему, было удачнее и логичнее. И функционал интересный реализован был на этом деле - редактирование любых объектов (документы, справочники) без их открытия - прямо в таблице ТаблицыЗначений на форме. В общем, советую ознакомится.
33. Ilya (i_volodin) 12.10.12 10:27
Извините, а резкое увеличение в модуле экспортных процерур - это меньшее зло?..
34. Сергей Филатов (mdfilsoft) 14.10.12 18:08
Статья актуальная и очень полезная. Меня самого немного бесит когда, например, при открытии какого нибудь документа он вдруг изменяется и если попытаться его сразу закрыть выдается сообщение с предложением сохранить изменения, хотя я (в данном случае как пользователь) никаких изменений не делал, а просто открыл документ, посмотреть его данные.

Хотелось только предложить маленькое усовершенствование для процедуры модуля формы УстановитьВидимостьДоступность().

В качестве параметра можно передавать элемент формы, видимость/доступность которого необходимо изменить. В теле процедуры нежно добавить необходимое количество условных операторов, которые будут проверять имя элемента управления. Для того чтобы данную процедуру можно было выводить из обработчика открытия формы можно вызывать данную процедуры без параметра.
Например:

Процедура УстановитьВидимостьДоступность(ЭлементФормы = Неопределено)

    // Валюта
    Если ЭлементФормы = Неопределено Или ЭлементФормы.Имя = "Валюта" Тогда
        Если Договор.Валюта = Валюты.Рубли Тогда
            ЭлементыФормы.Валюта.Доступность = Ложь;
        Иначе
            ЭлементыФормы.Валюта.Доступность = Истина;
        КонецЕсли;
    КонецЕсли;

КонецПроцедуры // УстановитьВидимостьДоступность()
...Показать Скрыть
35. Walter (WalterMort) 19.10.12 12:23
Не со всеми принципами согласен, но на безрыбье и рак рыба, так что плюсану. Вменяемыми регламентами порядка обработки событий нет даже в типовых, не то чтобы вменяемых, а вообще нет - каждый в свою сторону.

А не согласен, например, с единственной процедурой для прорисовки вида - порой форма может иметь довольно сложные "деформации" в зависимости от разных параметров. Выполнять полную "перерисовку" тогда, когда требуется смена видимости одного элемента не практично. Плюс процедура разрастается в монстра (см. РКО в УПП) и теряет управляемость что, в свою очередь порождает ошибки. Короче, я за автомат управления видом из нескольких функций. Принцип разделения данных и интерфейса, конечно, сохраняется.

Ну и к управляемым формам описанные принципы связи данных тоже не подходят.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа