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

Вот есть принципы SOLID, есть принцип D - принцип инверсии зависимостей.
Как его соблюсти, если на уровне предметной области в "заявку" - объект предметной области - надо добавить поле?

А слой взаимодействия с БД он идет отдельно, поидее. И слой взаимодействия с БД согласно принципу не должен быть привязан к предметной области.

Где я ошибаюсь в своих размышлениях?

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

Я кажется понял.

Надо херачить промежуточный формат, типа XDTO в случае 1С, чтобы организовать взаимодействие Компонент1С - XDTO - ДругойКомпонент1С

В таком случае внесение изменений в реквизиты на стороне "Компонент1С" не приведет к тому, что в "ДругойКомпонент1С" что-то сломается.

(0) давай попробую объяснить. Но сначала надо понять, что такое зависимости в коде

Процедура Первая()
    Вторая(1000);
КонецПроцедуры

Процедура Вторая(Параметр)    
    // Тут какой-то код
КонецПроцедуры

Метод Первая() зависит от метода Вторая(). Ибо Первая() "знает" о существовании Вторая(), и о том что в неё передавать. Вторая(), напротив, ничего не знает о Первая(). Вызывающую процедуру как бы не волнует, кто её вызывает. Так вот, чтобы инвентировать зависимости, надо код писать так, чтобы более низкоуровневая логика "знала" о более высокоуровневой, но высокоуровневая ничего не знала о низкоуровневой логике.

Теперь на примере

Процедура  СторнироватьОтрицательныеВзаиморасчеты()
    
    Запрос = Новый Запрос("// Какой-то запрос для получения отрицательных взаиморасчетов");
    СторнируемыеВзаиморасчеты = Запрос.Выполнить().Выгрузить();
    
    Для каждого ДанныеВзаиморасчетов Из СторнируемыеВзаиморасчеты Цикл    
        // Логика обработки данных    
    КонецЦикла;    
    
КонецПроцедуры

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

Процедура  СторнироватьОтрицательныеВзаиморасчеты(СторнируемыеВзаиморасчеты)
    
    Для каждого ДанныеВзаиморасчетов Из СторнируемыеВзаиморасчеты Цикл    
        // Логика обработки данных    
    КонецЦикла;    
    
КонецПроцедуры

Теперь метод СторнироватьОтрицательныеВзаиморасчеты() ничего не знает о том, откуда ему прилетели данные. Из БД, из файла или пользователь ввел их ручками. Соответственно, зависимость кода обработки взаиморасчетов инвентирована от работы с БД (и чем либо другим)

*Вызываемую процедуру как бы не волнует, кто её вызывает.

(1) >>Надо херачить промежуточный формат, типа XDTO в случае 1С

Совсем нет. В тру-программировании херачат DTO (Data Transfer Object), это далеко не то же самое, что XDTO. В случае с 1С DTO-шками будут данные, упакованные в универсальные коллекции: ТаблицаЗначений, Структура, Массив и т.д.

АдресДоставки = Новый Структура;
АдресДоставки.Вставить("Город", Город);
АдресДоставки.Вставить("Улица", Улица);
АдресДоставки.Вставить("Дом", Дом);
АдресДоставки.Вставить("Квартира", Квартира);

СоздатьЗаявкуНаДоставку(АдресДоставки);

АдресДоставки - и будет тем самым DTO. Самая суть, что метод СоздатьЗаявкуНаДоставку() не волнует, откуда был получен АдресДоставки. Он работает с универсальной коллекцией - структурой. А как и откуда структура была получена, его не волнует. Условно представим, что код формирующий АдресДоставки находится в слое работы с интерфейсом UI. А метод СоздатьЗаявкуНаДоставку() находится в слое бизнес-логики (Domain). Тогда слой работы с интерфейсом у нас зависит от слоя работы с бизнес-логикой, а АдресДоставки это наш условный DTO-объект, который перекатывает данные между слоями UI и Domain

(4) ответа на вопрос я не получил... но вообще как дополнение - хорошее. Спасибо.

Вопрос-то здесь: >>Как на уровне слоя взаимодействия с БД реализовать работу с таблицами СУБД? Через рефлекшн поступающих объектов, а у объектов поля должны быть соответствующим образом аннотированы?

т.е. уйдем от 1С и вернемся например в чистый код на ява без фреймворков, только есть у тебя СУБД допустим и JDBC

А, то есть херачат получается это: >>В тру-программировании херачат DTO (Data Transfer Object)?

(7) да. Если по джавовски, создаешь простые классы (можно даже с открытыми полями), без какой-либо логики в коде. И катаешь их.
Но есть тонкости, у тебя будет масса сервисных методов, которые должны работать с различными DTO-объектами. Чтобы выкрутиться, тебе нужно создать пустой интерфейс (без методов), и имплементировать его каждому DTO.  А в сервисных методах указывать не тип конкретных классов, а тип интерфейса

interface MyDataTransfers{}

class EmployeeFromDB implements MyDataTransfers {
String name;
int age;
// конструкторы
}

так ты сможешь передать EmployeeFromDB в сервисный метод

myServiceMethod(MyDataTransfers transferObject)

(8) но тогда странно получается.

на один предметный объект два класса: один для работы в контексте предметной области с бизнес-логикой, другой для работы с СУБД, так?

(9) +в принципе аналогия с 1С опять же: документ 1с и отдельно его описание в XDTO для обмена с другими системами

(9) так. Это принцип единственной ответственности, но всему должна быть мера

Ну в 1с дата  объекты уже отвязаны от бд

(9) ну, примерно так. Зато нет привязки к БД. Если завтра вместо БД возникнет HTTP-сервис, то бизнес-логика об этом ничего не узнает

(12) наоборот. Жёстко связаны

(12) в 1С у тебя элемент справочника, ты вызываешь метод Записать(), там под капотом платформа 1С на сервере сгенерирует к субд запрос вида UPDATE

в 1С здесь как раз наоборот, нарушение принципа.

+ (вот такие темы должны быть чаще на Мисте, а не про дурачков всех слоев)

(16) может показаться, что вся эта "культура программирования" к 1С отношения не имеет, но конкретно взглянув на принципы SOLID, я понял

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

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

(14)(15) всё-таки не совсем. В случае с 1с CRUD-операции берет на себя платформа

Дорвался просто до книг в перерыве, пока менял работу, сейчас Фаулера читаю :)

(18) вот именно, поэтому и жестко
например, есть другие способы организовать иерархический справочник с точки зрения СУБД, но в 1С все жестко привязано в платформе

>>архитектура типовых решений 1С пронизана этими принципами

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

Да, по-крайней мере часть классических паттернов применимы в 1с

v8: SOLID в 1С

вот нашел

Кстати говоря передача тех самых "мутабельных объектов" с сервера 1С на клиент 1С потому и невозможна: клиент 1С представляет из себя что-то вроде браузера с просмотром HTML страниц.

Поэтому наделаны такие "ДанныеФормыСтруктураСКоллекцией", которые можно туда-сюда передавать, пушо есть их аналог в JSON/XML-представлении, которое используется "под капотом" тонкого клиента

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

Фаулер пишет:

Расщепление множества бизнес"функций между сервером и клиентом выглядит как наихудшее решение, поскольку в общем случае затрудняет идентификацию того или иного фрагмента логики. Основная причина, побуждающая применять подобную архи" тектуру, может состоять в том, что клиенту необходимо владеть только какой"то частью бизнес"логики. Главное — изолировать эту порцию кода в отдельном модуле, не завися" щем от других частей системы. Это даст возможность активизировать код и на компьюте" ре клиента, и на сервере, если такая потребность возникнет позже. Такой подход, разуме" ется, требует дополнительных усилий, но они оправданны.

Вроде бы не про 1С написано, Фаулер даже понятия про 1С не имеет скорее всего, но ... насколько же это про 1С?

(25) +единственно что проблема применимости контекста клиента в контексте сервера, но если упороться и сделать обертки через аналоги DTO, то вполне жизнеспособно будет.
Правда - незачем, но...


Часто у вас возникала потребность создать документ программно, а часть кода необходимого при этом оказывалась в модуле формы в &НаКлиенте и вам приходилось ее переписывать?

(24) прям таки невозможна?
то есть структуры и массивы менее мутабельны чем таблицы значений?

(27) а это проблема уже вендора: они одним термином опять называют что-то свое, а не общепринятное в программировании.

в терминологии 1С, насколько я понимаю, структура и массив мутабельными не являются.

(28) тогда нужен термин мутабельного значения в рамках 1с

(29) а нету его.

На ИТС поискал - однозначного определения нет.

Вот документ "УстановкаЦенНоменклатуры" с кучей бизнес-логики, завязанной на представление - это проблема, которая должна была когда-то задеть каждого 1Сника.

(32) см https://habr.com/ru/post/657991/comments/#comment_24214407

(28) почему не являются?

Любой тип в рамках общих языков может быть как мутабельным так и немутабельным

(26) тут проблема чуть глобальнее. Грамотеи пихают код бизнес-логики в форму документа, и при программном создании документа этот код становится недоступным

Но в 1с не совсем поямое понимание мутабельности. Там оно означает возможность передачи на сервер

(32) таких документов полно в типовых. Особенно в ЗУПе. Там пошли ещё дальше: не просто бизнес-логику закатали в форму документа, но и бережно постарались связать её с интерфейсом. То есть если даже захочешь утащить код из формы в модуль объекта, у тебя это не получится, в этом коде сотни зависимостей от формы

(37) я думаю, что этот термин встречается в соответствующих сообщениях об ошибках, поэтому такое восприятие

признавайтесь, кто из вас статью накатал в вики
явно 1сник
https://ru.wikipedia.org/wiki/Изменяемый_тип

(40) историю правок можно же глянуть. В правом верхнем углу вкладки Читать | Править | Править код | История

(41) это такая шутка была

(42) а, понял

D - это когда вы отвязываетесь от классов и везде передаете интерфейсы, где это возможно.
как вы это реализуете в 1С без интерфейсов и строго типизации - нечто акробатическое и костыльное.
это как в Golang пытаться использовать dependency injection фреймворки.
если делать классическую гексагональную архитектуру, то у вас будет сервис, который будет в репозиторий гонять DTO-шки, а репозиторий будет ходить в базу.
но там другая проблема - у вас будет слишком много DTO-шек и ненужных сериализаций между слоями 1 в 1, Evrone использует 1 DTO структуру, которая гоняется сквозь слои.

а вот по (33), там есть такое
"Реквизиты - это публичные поля класса. Они автоматически доступны пользователю в интерфейсе. И они хранятся в БД вместе с объектом. Фактически, добавляя новое такое поле в свой класс, разработчик заставляет платформу в таблице SQL добавить новую колонку (или несколько для составных типов)."
.
поясните невосьмерочнику - для составного типа (например, составной тип СпрНоменклатура и СпрЕщеХреньКакаяТо) - для каждого из типов будет сгенерена отдельная колонка на уровне таблицы БД?

а вообще - вредная статья в (33) начитается неадекватная молодежь и рванет в 1С...

(45) максимум три поля:
1. тип поля (элементарный или ссылочный)
2. вид ссылки (идентификатор конкретного справочника, документа, ...)
3. сама ссылка

то есть это будет составной тип только на ПЯТЬ справочников, то будет два поля: 2-е и 3-е, т.к. в первом толку нет

(47) Нихрена не понял.
если составной тип на пять справочников то где будет указываться на какие конкретно пять справочников - в п.2? (пока в п.2 написано "идентификатор конкретного справочника.." - а куда будут запихнуты идентифкаторЫ всех пяти справочников?

yukon39 30.03.2022 в 12:33
По доступным к анализу признакам Конфигуратор набрал техдолга и захлебнулся. Новых изменений в него не вносят. EDT тоже уперся в Конфигуратор, т.к. сборка конфигурации сейчас доступна только в режиме конфигуратора.

!_На замену активно пишется с нуля автономный сервер, с yml-конфигами, работой только через http, и прочими современными фичами._!

(49) самодурственное заблуждение

(48) да, во второе поле
вообще об этом все написано на ИТС

(48) в дто! Т. Е. В конфигураторе. В самой таблички зачем эти знания?

(44)

>>как вы это реализуете в 1С без интерфейсов и строго типизации

дак очень просто.

Берешь пишешь код:

ИмяМодуляИнтеграции = "ИнтеграцияЯндексСервер";
МодульОбработкиИнтеграции = ОбщегоНазначения.ОбщийМодуль(ИмяМодуляИнтеграции);

МодульОбработкиИнтеграции.ПолучитьДанные();


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

(53) а лучше обработки, т.к. общие модули не хранят состояния (или все время параметрами передавать)

(53) дык костыльно, как я и сказал.

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

(55) там еще до кучи костыль внутри ОбщегоНазначения.ОбщийМодуль()
чтобы в рекурсию не входило

Еще вопрос возник.

Вроде бы все хорошо, солид/грасп/тосибоси

Но есть у нас в 1С Документ. Куда пихать бизнес-логику?

1. Модуль объекта - нельзя, т.к. потребуется вызывать из модуля формы, а для этого надо делать РеквизитФормыВЗначение
2. Модуль формы - вроде бы можно, но размещать в процедурах и функциях бизнес-логику? Как-то противоречит принципам солид/грасп
3. Модуль менеджера - вроде бы нормально
4. Общий модуль - разумно для случая, если бизнес-логика используется несколькими объектами, а не только текущим документом.

Вообще 1С перейдя на УФ лишила возможности использовать модуль объекта для программирования бизнес-логики, т.к. РеквизитФормыВЗначение не рекомендуется использовать например для заполнения таб. части документа.

Обращаю внимание, что в ЕРП 2.5 вендор выкинул бизнес-логику проведения документа в модуль менеджера и вообще в общие модуля под общим названием "Учетные механизмы конфигурации"

В модуле объекта осталась только технологическая логика проведения документа (отражение движений через другие общие модуля)

(58) а проведение - это уже не бизнес-логика?

(58) чем вас общий модуль-то не устроил? Ну пускай будет вызываться пока для 1 документа, может потом для еще одно понадобится)

в модуле формы бизнес-логике точно не место. там только логика UI должна быть

(62) вендор эту традицию только так нарушает

(63) В УТ11 более менее поддерживает, все в общие модули вынесено. Удобно программно создавать и заполнять документы

(58) откуда инфа про "не рекомендуется"?

если логика связана с поведением конкретного экземпляра объекта метаданных, то ей место в модуле объекта.
если логика связана с конкретным видом метаданных, но не с экземпляром, то её место в менеджере.
в иных случаях - общий модуль, либо обработка

(63) Эта традиция называется MVC

(66)
>>если логика связана с поведением конкретного экземпляра объекта метаданных, то ей место в модуле объекта.

это все хорошо, но нужно вызывать ресурсоемкий РеквизитФормыВЗначение("Объект"), а потом возвращать это назад

(68) это уже детали реализации, может подойти и что-то вроде Документы.ИмяДок.СоздатьДокумент()

(68) у тебя при проведении оно и так вызовется неявно

(69) по мне так проще: ПродажиСервер.МояСуперПроцедураДляБизнесЛогики(Объект, СтруктураДанных)

(68) это к оптимизации.
Есть же методики уменьшения серверных вызовов и все такое

(68) насколько ресурсоёмкий? На целый мегабайт оперативы?

Щас глянул типовую реализацию в ЕРП.

При изменении соглашения:

ДокументПродажи = РеквизитФормыВЗначение("Объект");
ДокументПродажи.ЗаполнитьУсловияПродажПоСоглашению();
ОтветственныеЛицаСервер.ЗаполнитьМенеджера(ДокументПродажи);
ЗначениеВРеквизитФормы(ДокументПродажи, "Объект");

думаю вопрос можно закрывать.

(74) +потом у них 1С на упр формах тормозит, а на обычных формах все норм было)

Сам думаю размещу в модуле менеджера, хоть это и противоречит правильному, описанному в (66)

Нет. В модуле менеджера размещать такое - херовое решение.

(0) Советую почитать книгу о SOLID автора, который и придумал этот ваш SOLID. В ней он несколько раз упоминает, что правила - не абсолютны, архитектор должен придерживаться их, но не следовать постоянно: https://i.yapx.cc/SW1OT.jpg

(77) переходите на темную сторону - размещайте в блокнотике бизнес-логику, а в процедуре просто Выполнить(ТекстИзБлокнота) =)

(78) правила не абсолютный, но вот конкретный вопрос про 1С и документ

где размещать бизнес-логику документа?

жертвовать производительностью и использовать РеквизитФормыВЗначение? вендор делает именно так, судя по всему

(80) где конкретный вопрос-то?

(81) >>где размещать бизнес-логику документа?

(80) >>жертвовать производительностью и использовать РеквизитФормыВЗначение?

Нечем там жертвовать. Ты пытаешься экономить на спичках

(82) тебе уже ответили в (66), что бизнес-логика разная бывает
Бизнес-логика - это часть предметной области. Документ - реализация.
Что ты вкладываешь в понятие "бизнес-логика документа" - хз

(84) в понятие "бизнес-логика документа" я вкладываю бизнес-логику конкретного экземпляра документа.

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

Худший вариант, когда у тебя часть логики вынесено в какую-то обработку, которая где-то там регламентом по чиху запускается, и меняет документы по своему усмотрению.
Ты закопаешься такое искать в случае чего.
Вон, пресловутая обработка обновления конфигурации. Если оно нормально отработало - ну и пускай бы с ней. Но если что-то пошло не так, то можно провести кучу времени в недрах отладчика, но так и не найти причину.

(87) так БСП оно все такое. Хорошо только пока все хорошо. Но прям таки анти дебаг френдли

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

(82) Делаешь общий модуль. Называешь его "Бизнес-логика". И пишешь все туда

(89)почему ссылки, а не объекта.
ведь при проведении всегда объект получается

(91) если мы проводим из формы списка или по результату запроса, то зачем поднимать весь объект, если документ уже был проведен?
Модуль объекта должен отвечать за целостность своего состояния

(92) ну так поднимается же

(93) увы да

(92) ну так объект все-равно поднимать надо, хотя бы ради реквизитов, на основании которых формируется движение

Ребят, этот вопрос не актуален.
У вендора РеквизитФормыВЗначение - 3000 вхождений на конфу ЕРП.

(95) мы же помним, что движения формируются из запроса, но не объекта

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

(98) они там кеширование обещали,но так и не доделали.

Когда в 1с у объектов появятся нехранимые поля и когда будут события сериализации и десертализации,то это будет большой шаг вперед.

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