это вопрос не к платформе, а к разработчикам прикладного решения, а еще раньше к консультантам, которые данное прикладное решение выбрали. Если на 1С написать хрень собачью, то будет хрень собачья написанная на 1С. Если хрень собачью написать на C#, то будет хрень собачья написанная на си шарп. Что будет если написать хрень собачью на lsFusion никто не знает, возможно это будет радуга с розовыми единорогами… ведь никто никогда этого не делал
Я имел в виду девелопмент у конечного заказчика. В 90 % случаев он сводится к настройке типового решения. Увы это так. Все остальное это узкоспециализировано и малопригодно для «решения из коробки». Не типовые решения существуют, но их очень мало. Но это не особенность платформы, а особенность российского бизнеса. Если на западе «best practices» что-то значит и твоя карьера действительно зависит от того, насколько ты хорошо эти практики знаешь, то в России все несколько по другому. Зачастую ход процесса внедрения зависит от компетенции топ-менеджмента. Зачастую многие топы сами не понимаю чего они хотят, но твердо уверены, что если поставить 1С то все у них будет в шоколаде. Качество платформы 1С тут обсолютно не причем.
Если сравнивать 8.3 с той же самой 8.0 — то разница глобальная. Возможно в 8.4 будут те же самые представления и передача функций в качестве параметров. Другой вопрос — зачем это нужно? Есть задачи с которыми 1С справляется на УРА оставляя позади конкурентов (в России Бухгалтерия Предприятия 3.0 это отраслевой стандарт де факто), есть задачи где эску лучше не использовать (как-то видел интернет магазин на http сервисе). В конкретно каждом случае нужны конкретные решения.
П. С. согласен что замыканий на самом деле не хватает, но я в принципе изначально об этом написал — асинхронности в 1С мало. Автор статьи же заявляет что отказ от синхронности как один из недостатков
В 150 раз. Тезис простой — ORM в 1С есть (пережиток 7.7 или нет не важно). Он убогий, и 1С решили от него отказаться и правильно сделали (тут конечно ORM'ки не согласятся, но имеют право). Вы же просто подтвердили, что я написал.
Тут разговор был о том, что автор не до конца понимает различие между объектом и ссылкой 1С а не ОРМ. Цитата В 1С объект читается всегда целиком, в том числе с табличными частями, но не более того (без каких либо связанных данных). Как следствие, данных читается… либо слишком много — если надо получить только одно поле (реквизит). Зачем создавать объект в 1С когда требуется прочитать один реквизит? Объясните мне что тут хотел донести до читателя автор, ведь с точки зрения 1С это абсолютная тупость. Этот момент у меня не укладывается в голове, хотя опыт использования SQLAlchemy у меня есть.
Я это знаю, меня интересует из-за чего у Вас подгорает? Вам хочется комфорта и эффективности, но эска к Вам несправедливо сурова? Вам что-то мешает создать решение, выложить его в открытый доступ, чтобы люди пользовались и радовались? Как взаимосвязаны процессы внедрения 1С с критикой качества платформы в этой статье?
Что о них нужно думать? Я не отрицаю что существуют конфигурации написанные «с нуля» и они где-то используются. Но в основной своей массе, именно так как я и говорил. Внедрение = настройка типового решения. И чем дальше, тем процесс более очевидный.
Автор путает мягкое с теплым, к тому же знания автора об 1С всеобъемлющие но не доскональные, а в некоторых местах автор сам признается, что некоторую идеологию 1С он трактует неправильно:
Фактически ключевое отличие этих двух понятий заключается в том, что объекты используются для записи и чтения, а ссылки — только для чтения
Объекты используются только для записи! в тоже время ссылки никогда не должны использоваться для чтения данных. Ссылка — в терминах sql это первичный ключ таблицы плюс сама таблица. Таким образом если метаобъект в конфигурации является ссылочным типом, то по ссылке мы можем получить указатель на таблицу базы данных плюс конкретную запись в этой таблице. Если же нужен доступ к данным, то как и в классическом SQL нужно использовать запрос. И в высоко нагруженных системах так и должно происходить. Обращение к реквизиту по ссылке допустимо, но скорее всего оставлено как пережиток прошлого из 7.7, где самого понятия ссылочного типа не было в явной форме.
В принципе этого уже достаточно, чтобы скептически относится к рассуждениям автора, на тему «почему 1с плохая и даже убогая». Но тем не менее позвольте пройтись по некоторым пунктам…
В 1С объект читается всегда целиком, в том числе с табличными частями, но не более того (без каких либо связанных данных). Как следствие, данных читается:
либо слишком много — если надо получить только одно поле (реквизит)
либо слишком мало — если в цикле надо обращаться к другим объектам по ссылке, мы получаем классическую проблему N+1 (один запрос для получения N объектов и по одному запросу для каждой ссылки).
Зачем создавать объект, чтобы прочитать только один реквизит? Для каких целей понадобилось обращаться к другим объектам в цикле? Что это за конструкция такая, в которой данные объекта зависят от других объектов? Автор тут конкретно не догоняет, что такое объекты и для чего они нужны. Но тем не менее делает вполне конкретный вывод
Такая убогость механизма ORM в 1С на самом деле обусловлена тем, что...
далее про регистры
Являясь по сути не более чем представлениями в SQL, усовершенствованными для работы со временем, представления в 1С наследуют (а иногда даже и усугубляют) все проблемы представлений в SQL.
тут автор совсем не понимает, что такое регистр. По его мнению регистр это одна таблица плюс его представление (СрезПоследних, ОстаткиИОбороты и т.д.). На самом деле все гораздо сложнее: регистр в 1с это агрегирующий объект и связан он не с представлениями (aka View), а с промежуточными итогами, которые на самом деле представлениями никак не являются. Не знаком с lsFusion чуть менее чем совсем, но в одном из how-to там увидел механизм контроля остатков (Управление материальными запасами) receivedQuantity 'Суммарный приход' = GROUP SUM quantity(ReceiptDetail d) BY item(d), stock(receipt(d));
shippedQuantity 'Суммарный расход' = GROUP SUM quantity(ShipmentDetail d) BY item(d), stock(shipment(d));
currentBalance 'Текущий остаток' (Item i, Stock s) = receivedQuantity (i, s) (-) shippedQuantity (i, s);
т.е. чтобы посчитать остаток запаса на складе, нужно взять приход и вычесть из него расход. Только хочется посмотреть, как это будет работать если записей в таблице овер дофига и нужно внести изменения «задним» числом. Тут конечно можно порассуждать, а давайте отделим оперативную базу от аналитической и вместо одного решения у нас будет два, а потому будем объяснять главному бухгалтеру, почему вчера эта циферка была такой, а сегодня она другая.
Фактически, регистры в 1С поддерживают всего две операции: сумма и последнее по дате, сгруппированные по ключам таблицы
промежуточные итоги они еще поддерживают. Сумму можно узнать за любой промежуток времени и последнее по дате можно узнать на любую дату. Представления конечно было бы круто иметь, только отсутствие оного особого неудобства это не создает. Если для каких-то особых задач оно все-таки понадобиться, то представления можно сделать средствами SQL, ведь доступ к физической модели ЕСТЬ, хоть автор и утверждает обратное. Но представлений в 1С нету не изза того что 1С не может их сделать. Они просто не нужны для выполнения тех задач, под которые 1С заточена.
В параметрах виртуальных таблиц можно использовать только константы
Автор имеет представление что такое виртуальная таблица, но как ей пользоваться — нет, к тому же сравнение ее с представлением неправильно. Виртуальная таблица — это не представление, а результат запроса к таблице регистра (движения плюс промежуточные итоги). Соответственно если параметры виртуальной таблицы меняются, то меняется и сама таблица. Как пример автор приводит абсолютно неоптимальный запрос, рабочий но не оптимальный. Скорее всего это изза того, что автор про пакетное исполнение запроса ничего не слышал.
Но так как, в отличии от SQL, в запросах 1С отсутствует механизм изменения данных (так называемый DML), использование запросов никак не может помочь в вопросах записи большого количества данных. То есть, если вам понадобится создать сто тысяч дисконтных карт, вам придется вернуться назад в ORM
было бы круто в 1с писать чтото «ОБНОВИТЬ РасходнаяНакладная КАК рн УСТАНОВИТЬ рн.Статус=ЗНАЧЕНИЕ(Перечисление.СтатусыРасходныхНакладных.Отгружена) ГДЕ рн.Ссылка = &Ссылка)». Порой этого действительно не хватает, если рассматривать данные когда они отделены от алгоритмов их обработки. К примеру выше если накладная закрыта, то нужно увеличить задолженность контрагента. Но на практике это редко применимо, в основном это требуется, когда нужно срочно чтото исправить, потому что ктото накосячил или при первоначальном заполнении (как часто требуется создание ста тысяч дисконтных карт?).
Верхом садизма при этом является отсутствие в 1С замыканий и передачи функций в качестве параметров. То есть переменные контекста нужно самому сохранять, например, в какую-нибудь структуру, после чего передавать эту структуру параметром явно созданной и именованной процедуре обработке результата. В итоге получается что-то зубодробительное вроде
Тут вообще ничего не понятно. Тот же самый питон движется в сторону отказа от синхронного многопоточного программирования в сторону корутин и асинхронных вызовов. Что не так с асинхронностью в 1С? А я скажу что не так: его там мало! Оно там используется только в тот момент, когда требуется прервать поток для ожидания действий пользователя. У разработчика нет возможности созданиях асинхронных вызовов и когда оно действительно нужно, приходится уже изголяться.
Соответственно для этого в 1С и отделили данные формы от просто данных, но при этом в попытках сделать это разделение менее явным создали ряд очень странных абстракций. Например, класс в скобочках. Который выглядит как класс, крякает как класс, но не класс (например методы этого класса вызывать нельзя)
Данные формы не являются данными объекта. Данные формы это отображение данных объекта. Т.е. открыть форму не подразумевает под собой открыть объект. Объект создается в момент записи данных формы, а не в процессе открытия формы. Если понимать как это работает, то на самом деле можно создавать довольно универсальные вещи. Обобщенно в большинстве случаев данные формы должны равняться данными объекта, но в ряде случаев 1С позволяет создавать универсальные формы, для различных объектов (см. конфигурацию Документооборот, как там реализован механизм вызова формы задачи бизнес процесса). Если понимать как это работает — можно создавать достаточно интересные вещи.
И если с данными формы такое разделение было во многом вынужденным, то зачем понадобилось разделять команды формы и действия, я, если честно, не совсем понял. Может в комментариях кто-нибудь сможет это объяснить
Какие действия?
В общем получился какой-то франкенштейн, который при этом по функционалу пересекается с половиной других абстракций в 1С. В которые (например, формы) они еще и попытались интегрировать этот СКД. В результате понять что, где, когда и как нужно использовать — задача весьма неочевидная
Рядовому пользователю нет необходимости понимать как работает СКД, в 99% случаев ему нужно настроить вариант отчета, с которым он потом и будет работать. Другой аспект — это СКД с точки зрения разработчика. Механизм достаточно сложный, но если его освоить, то скорость разработки отчетов и интерактивной выборки данных (а именно для этого используется СКД), повышается в разы и там нет никакой громоздкости.
Как интерактивный интерфейс, то есть замена формам, СКД также плохо подходит, так как не умеет и половину того, что умеют формы
Автор опять путает теплое с мягким. Зачем сравнивать СКД с формой? Это как? СКД не умеет многое того что умеет форма? Это тоже самое что лошадь не умеет много того, что умеет кофеварка. На самом деле открывая СКД автор, открывает форму, если СКД в отчете, то открывается форма отчета указанная в настройках, и она может быть универсальная, одна на всех. А может быть своя собственная, конкретно для данного случая. Гибко и просто.
Про фатальные недостатки хочется спросить только одно? ЗАЧЕМ???
Фатально — это значит обреченно. 1С обречена из-за того не умеет GIT и Eclipse? Зачем нужен PIP в 1С?
Зачем нужные открытые репозитории в 1С когда весь девелопемент в 1С сводится к настройке типового решения, и этот девелопемент в 100% сугубо индивидуален для каждого заказчика. В большинстве случаев растиражировать готовое решение для конкретного заказчика на массовый сегмент — это не что иное, как пердеть в океане. Я понимаю в питоне форкнуть чужой проект, внести в него корректировки, установить зависимости и выложить обратно на GIT, как-то оправдно с точки зрения того, что это потом кому-то будет нужно. Но в 1С это зачем? Думаете кому-то поднадобится шлак, который Вы внедрили в ООО «Рога и Копыта»? Внедрений в 1С сделаны сотни тысяч, до отраслевых решений дошли всего десятки, и все эти решения получили статус «1С совместимо» и лежат в официальном репозитории 1С. И там есть контроль версий!!!
Если это утверждение верно, не проще ли бы было скопировать ключи с токена в реестр и на этом закончить решение проблемы?
это вопрос не к платформе, а к разработчикам прикладного решения, а еще раньше к консультантам, которые данное прикладное решение выбрали. Если на 1С написать хрень собачью, то будет хрень собачья написанная на 1С. Если хрень собачью написать на C#, то будет хрень собачья написанная на си шарп. Что будет если написать хрень собачью на lsFusion никто не знает, возможно это будет радуга с розовыми единорогами… ведь никто никогда этого не делал
П. С. согласен что замыканий на самом деле не хватает, но я в принципе изначально об этом написал — асинхронности в 1С мало. Автор статьи же заявляет что отказ от синхронности как один из недостатков
Тут разговор был о том, что автор не до конца понимает различие между объектом и ссылкой 1С а не ОРМ. Цитата В 1С объект читается всегда целиком, в том числе с табличными частями, но не более того (без каких либо связанных данных). Как следствие, данных читается… либо слишком много — если надо получить только одно поле (реквизит). Зачем создавать объект в 1С когда требуется прочитать один реквизит? Объясните мне что тут хотел донести до читателя автор, ведь с точки зрения 1С это абсолютная тупость. Этот момент у меня не укладывается в голове, хотя опыт использования SQLAlchemy у меня есть.
Объекты используются только для записи! в тоже время ссылки никогда не должны использоваться для чтения данных. Ссылка — в терминах sql это первичный ключ таблицы плюс сама таблица. Таким образом если метаобъект в конфигурации является ссылочным типом, то по ссылке мы можем получить указатель на таблицу базы данных плюс конкретную запись в этой таблице. Если же нужен доступ к данным, то как и в классическом SQL нужно использовать запрос. И в высоко нагруженных системах так и должно происходить. Обращение к реквизиту по ссылке допустимо, но скорее всего оставлено как пережиток прошлого из 7.7, где самого понятия ссылочного типа не было в явной форме.
В принципе этого уже достаточно, чтобы скептически относится к рассуждениям автора, на тему «почему 1с плохая и даже убогая». Но тем не менее позвольте пройтись по некоторым пунктам…
Зачем создавать объект, чтобы прочитать только один реквизит? Для каких целей понадобилось обращаться к другим объектам в цикле? Что это за конструкция такая, в которой данные объекта зависят от других объектов? Автор тут конкретно не догоняет, что такое объекты и для чего они нужны. Но тем не менее делает вполне конкретный вывод
далее про регистры
тут автор совсем не понимает, что такое регистр. По его мнению регистр это одна таблица плюс его представление (СрезПоследних, ОстаткиИОбороты и т.д.). На самом деле все гораздо сложнее: регистр в 1с это агрегирующий объект и связан он не с представлениями (aka View), а с промежуточными итогами, которые на самом деле представлениями никак не являются. Не знаком с lsFusion чуть менее чем совсем, но в одном из how-to там увидел механизм контроля остатков (Управление материальными запасами)
receivedQuantity 'Суммарный приход' = GROUP SUM quantity(ReceiptDetail d) BY item(d), stock(receipt(d));shippedQuantity 'Суммарный расход' = GROUP SUM quantity(ShipmentDetail d) BY item(d), stock(shipment(d));
currentBalance 'Текущий остаток' (Item i, Stock s) = receivedQuantity (i, s) (-) shippedQuantity (i, s);
т.е. чтобы посчитать остаток запаса на складе, нужно взять приход и вычесть из него расход. Только хочется посмотреть, как это будет работать если записей в таблице овер дофига и нужно внести изменения «задним» числом. Тут конечно можно порассуждать, а давайте отделим оперативную базу от аналитической и вместо одного решения у нас будет два, а потому будем объяснять главному бухгалтеру, почему вчера эта циферка была такой, а сегодня она другая.
промежуточные итоги они еще поддерживают. Сумму можно узнать за любой промежуток времени и последнее по дате можно узнать на любую дату. Представления конечно было бы круто иметь, только отсутствие оного особого неудобства это не создает. Если для каких-то особых задач оно все-таки понадобиться, то представления можно сделать средствами SQL, ведь доступ к физической модели ЕСТЬ, хоть автор и утверждает обратное. Но представлений в 1С нету не изза того что 1С не может их сделать. Они просто не нужны для выполнения тех задач, под которые 1С заточена.
Автор имеет представление что такое виртуальная таблица, но как ей пользоваться — нет, к тому же сравнение ее с представлением неправильно. Виртуальная таблица — это не представление, а результат запроса к таблице регистра (движения плюс промежуточные итоги). Соответственно если параметры виртуальной таблицы меняются, то меняется и сама таблица. Как пример автор приводит абсолютно неоптимальный запрос, рабочий но не оптимальный. Скорее всего это изза того, что автор про пакетное исполнение запроса ничего не слышал.
было бы круто в 1с писать чтото «ОБНОВИТЬ РасходнаяНакладная КАК рн УСТАНОВИТЬ рн.Статус=ЗНАЧЕНИЕ(Перечисление.СтатусыРасходныхНакладных.Отгружена) ГДЕ рн.Ссылка = &Ссылка)». Порой этого действительно не хватает, если рассматривать данные когда они отделены от алгоритмов их обработки. К примеру выше если накладная закрыта, то нужно увеличить задолженность контрагента. Но на практике это редко применимо, в основном это требуется, когда нужно срочно чтото исправить, потому что ктото накосячил или при первоначальном заполнении (как часто требуется создание ста тысяч дисконтных карт?).
Тут вообще ничего не понятно. Тот же самый питон движется в сторону отказа от синхронного многопоточного программирования в сторону корутин и асинхронных вызовов. Что не так с асинхронностью в 1С? А я скажу что не так: его там мало! Оно там используется только в тот момент, когда требуется прервать поток для ожидания действий пользователя. У разработчика нет возможности созданиях асинхронных вызовов и когда оно действительно нужно, приходится уже изголяться.
Данные формы не являются данными объекта. Данные формы это отображение данных объекта. Т.е. открыть форму не подразумевает под собой открыть объект. Объект создается в момент записи данных формы, а не в процессе открытия формы. Если понимать как это работает, то на самом деле можно создавать довольно универсальные вещи. Обобщенно в большинстве случаев данные формы должны равняться данными объекта, но в ряде случаев 1С позволяет создавать универсальные формы, для различных объектов (см. конфигурацию Документооборот, как там реализован механизм вызова формы задачи бизнес процесса). Если понимать как это работает — можно создавать достаточно интересные вещи.
Какие действия?
Рядовому пользователю нет необходимости понимать как работает СКД, в 99% случаев ему нужно настроить вариант отчета, с которым он потом и будет работать. Другой аспект — это СКД с точки зрения разработчика. Механизм достаточно сложный, но если его освоить, то скорость разработки отчетов и интерактивной выборки данных (а именно для этого используется СКД), повышается в разы и там нет никакой громоздкости.
Автор опять путает теплое с мягким. Зачем сравнивать СКД с формой? Это как? СКД не умеет многое того что умеет форма? Это тоже самое что лошадь не умеет много того, что умеет кофеварка. На самом деле открывая СКД автор, открывает форму, если СКД в отчете, то открывается форма отчета указанная в настройках, и она может быть универсальная, одна на всех. А может быть своя собственная, конкретно для данного случая. Гибко и просто.
Про фатальные недостатки хочется спросить только одно? ЗАЧЕМ???
Фатально — это значит обреченно. 1С обречена из-за того не умеет GIT и Eclipse? Зачем нужен PIP в 1С?
Зачем нужные открытые репозитории в 1С когда весь девелопемент в 1С сводится к настройке типового решения, и этот девелопемент в 100% сугубо индивидуален для каждого заказчика. В большинстве случаев растиражировать готовое решение для конкретного заказчика на массовый сегмент — это не что иное, как пердеть в океане. Я понимаю в питоне форкнуть чужой проект, внести в него корректировки, установить зависимости и выложить обратно на GIT, как-то оправдно с точки зрения того, что это потом кому-то будет нужно. Но в 1С это зачем? Думаете кому-то поднадобится шлак, который Вы внедрили в ООО «Рога и Копыта»? Внедрений в 1С сделаны сотни тысяч, до отраслевых решений дошли всего десятки, и все эти решения получили статус «1С совместимо» и лежат в официальном репозитории 1С. И там есть контроль версий!!!