Внедрение зависимостей в 1С. DI на ОСени
Вставка
- Опубліковано 28 сер 2024
- В гостях у Желтого клуба Никита Иванченко.
Обсуждаем с Никитой зачем использовать DI. Какие варианты организации IoC-контейнера есть у 1С программистов. Никита показывает на примере ОСени создание и использование IoC-контейнера в OneScript для внедрения зависимостей.
НАВИГАЦИЯ
Скоро будет
ДОП. МАТЕРИАЛЫ:
Донатить пацанам тут: oscript.io/
ОСень github.com/aut...
OneScript github.com/Evi...
Репозиторий стрима github.com/Niv...
#ОСень #OneScript #DI
==========
Информационные площадки "Жёлтого клуба":
Телеграмм канал: t.me/+h2Ipfl1G...
Телеграм чат: t.me/yellowclu...
Группа ВКонтакте: vk: yellowc...
Подписывайся на канала Желтого клуба, чтобы не пропустить интересных гостей
/ @yellow_club
Никита, спасибо большое, отличный и наглядный пример. Классный стрим, посмотрел с удовольствием, пойду читать про оскрипт
Магия на желудях))
30 минута - нефига не понятно.... Что такое инджект....
Это нормально) не переживай
Были вопросы в чате стрима про отладку. Отладка в оскрипте есть 👍
прошу "мини" курс по Осени... нефига не понял как она работает...
Поддерживаю, очень интересно и хочется разобраться
Чтобы понять, как ей пользоваться достатояно прочесть документацию. Чтобы понять, как она работает - надо залезать в код. Если коротко - на рефлексии. С помощью саецивльного объекта Рефлектор, который есть в оскрипте и нет в платформе, анализируется состав классов, доступных к использованию, сохраняется информация об их методах, свойствах, аннотациях, зависимостях. Метод НайтиЖёлудь или ЗапуститьПриложение начинает разматывает все зависимости и инициализирует нужные объекты в правильной последовательности.
@nixel2007 чтооооооо документацию ещё читать ???? Ты в своём уме ?)
Зачем напрягать глаза чтением, можно же просто послушать и посмотреть.
Может кто то плохо читает и читать 10 листов у человека занимает дней 10, а видео посмотреть за день можно.
@@Jimmo910 обычно в видео опускают многие моменты, описанные в документации, теряя важные для понимания работы особенности. Либо это будет видео с полным чтением документации. Может в нейросеть можно загнать, сгенерить, но я уверен, что в случае просмотра примеров кода это будет менее удобно. Скорость чтения может не подойти, останавливаться и возвращаться к уже рассказанным моментам не удобно, поиска нет вообще, обновлять такую видеодокументацию намного сложнее, а значит, она постоянно будет неактуальной. Ну и зачем такое нужно?
Вот было это видео с обзоркой на 2 часа. И вам все равно что-то не понятно. Посмотрите вы доклад Никиты на ИЭ, мастер класс или лекцию в Лектории. И все равно что-то останется непонятно. А времени потратите ощутимо больше.
DI на ОСени на стальной броне.
Рев моторов глушит шум дождя.
Прикольно, но не понятно для чего велосипед в виде web-фрейморка, когда есть python начиная с bottle (для запуска которого нужно ПЯТЬ, КАРЛ, ПЯТЬ строк) заканчивая django. Типа на 1с подобном языке? p.s. Парни молодцы, что написали все это. может os и вырастет когда-то в python, но не при нашей жизни ) размер комьюнити, как сказал автор, как и все маленький!
Растёт комьюнити, может и станут стандартом в индустрии. Как знать.
Держим за ребят кулачки
Для запуска winow нужно три строки, причём две их них - импорт других библиотек :)
Можно без кода, из командной строки 😉 winow start
Каждый кулик хочет иметь свое болото!
кепка дурацкая
Ржунемогу) труба все выдает этих конфигуристов😂🎉🎉
Внедрение зависимостей в 1С. DI не возможен. Расходимся. Можно не тратить полтора часа своего времени
1С это про бухгалтерию. А это какие то секстанты! Отход от линии партии Нуралиевых
Не совсем верно. 1с это Фреймворк для построения приложений и систем ведения учёта.
@@user-jl6dq8qf1h правильно, для приложений и систем ВЕДЕНИЯ УЧЕТА. Все остальное сделать там невозможно либо не имеет смысла
А что скажет по этому вопросу Борис Нуралиев ?
Какому именно? Концепция di или существование оскрипта ?
Мне кажется, ценность курса Евгения и его ментора как раз в том, что там подобные концепции рассматриваются в призме реального 1С. Надеюсь на это.
Недавно, на волне хайпа вокруг курса решил все-таки начинать становиться программистом (да, 1С программисты - не программисты, их никто не учил программировать, потребности не было...), купил литературы соответствующей, читаю. Плююсь на свое профильное образование, на котором этому не учили и эту литературу не давали. В принципе, на примерах ООП понятно.
Но вот как многое из того, о чем читаю, переложить на 1С пока что не понятно.
Ладно, классов в 1С произвольных нет. Ну, типа, есть обработки и форму можно получить на клиенте (закроем глаза на серверный вызов, ага), но это бред.
Нет произвольных классов - нет сокрытия. Вообще. Все на договоренностях и контрактах строится.
Вот сделал я свою имитацию класса на структурах данных. Написал к нему общий модуль - программный интерфейс, чтобы с ним работать. И при этом еще и вынужден в особо критичных моментах проверять, а не нарушил ли клиент (потребитель) котракта и не ковырялся в моем "классе" напрямую как в структуре данных.
DI, вот. На процедурном языке программирования - хрен сделаешь нормально. Можно синтетикой усложнять, да. Создавать "имитации" классов на структурах данных, к ним "имитации" конструкторов, подкидывать в "поля" (свойства в глубине этого контейнера) зависимости. В принципе, так и делаю. Сам сомневаюсь, читаем ли вообще такой код. И обязываю клиента слишком много правил соблюдать при работе с этим (для типичного 1С).
Просто, повторюсь, мне кажется, создавать для "класса" экземпляр Обработки - это слишком. Накладные расходы, плюс доступность только на сервере. Я много кода пишу КлиентСерверного контекста и создаю много контейнеров-структур, к которым отношусь как к классам. Ну да, методы положил отдельно, рядышком. А как иначе то в 1С?
На курс пока не попасть, но там было бы интересно услышать мнения по этому поводу. Если они у авторов есть.
Все правильно пишешь.
Что касается DI и процедурного Программирования, то абсолютно верно. В 1С не возникает тех проблем, которые IoC контейнер призван решать. У нас событийно ориентированное программируем и мы просто вписываемся в точки, которые предоставляет нам платформа. Не бывает задач в 1С, где нужно в одном серверном вызове управлять 50 объектами. Поэтому проще через Новый создавать и не париться.
А вот пример с инжектом в параметры методов это хорошо и это надо делать
Если ты не программист, не обобщай на всех 1с-ников.
Слабо связанный код тоже имеет ряд своих недостатков, учитывая что код 1С это по-большей части код однопоточного исполнения, применение этого паттерна разработки в 1С только значительно усложнит отладку и чтение кода, при этом такой подход никак не влияет на производительность конечного решения, в ваших простых примерах это незаметно, но если кусочки слабо связанного кода в типовой ЗУП начнут выносить в расширения и что-то в них менять, а после этого перестанет заполняться какой-нибудь регл отчет, вот тут начнется вешалка для всего отдела разработки, который этой хеpнeй занимается.
Без DI в хотя-бы какой-то мере, становится почти невозможно писать unit-тесты. Я свечку не держу, но сомневаюсь, что разработчики ЗУП эти тесты пишут.
Советуется искать некую золотую середину путем того что подумать, а как бы я стал писать тест на свою новую функцию. Пример с печатной формой в начале видео - хороший. Если мы пишем тест на функцию создания табличного документа, мы не хотим косвенно во время него опираться на логику получения данных. Мы хотим получение данных отдельно тестировать. Поэтому данные неплохо было бы передать в параметр метода. И тому подобное.
@@LosashExote золотая середина это выкинуть 1С к х..м и писать на другом. Если начинаешь использовать тесты, DI, CI зачем тогда вообще 1С? проще взять какой нибудь зрелый язык и его использовать. Потому как иначе получается каша из топора.