А почему нельзя решить это подсчетом ссылок при выходе из области видимости или при записи в ссылочное поле?
B func() {
var a = new A(); // refCntNewA = 1
var b = new B(); // refCntNewB = 1
b->field = a; // refCntNewA++ (2)
a->field = b; // refCntNewB++ (2)
// refCntNewA--; get ref for a->field; refCntNewB-- (1, 1)
return b; // refCntNewB++; refCntNewB-- (1)
}
var b = func(); // refCntNewB++; refCntNewB-- (1)
b->field = null; // refCntNewA-- (0, free memory newA)
То есть это тоже расходы в рантайме, но это не совсем gc. Количество ссылочных полей в классе известно при компиляции, компилятор может подготовить нужные инструкции. Всё в компайл-тайме и не проверишь, количество ссылок может зависеть от входных данных в рантайме.
Цель "построить утюг" совершенно не та же самая, что и цель "грамотно использовать утюг".
Ну я вам так и сказал, вы путаете инженеров с домохозяйками. Домохозяйка не знает, как работает утюг и как его построить.
Особенно, если никто не понимает до сих пор, что такое это самое "грамотно использовать".
Нет, не понимают как раз как построить. Использовать ИИ хотят так же, как ЕИ - сказал задачу словами, он понял и сделал как нужно.
Мнение инженеров по вопросам проблем красного смещения нерелевантно совсем
Мы говорим не о приборе, который измеряет параметры интеллекта, а о самом интеллекте. "Специалисты, которые строят интеллект" в вашей аналогии будут "специалисты, которые воспроизводят в лаборатории красное смещение". Их мнение в изучении этого вопроса очень даже релевантно.
Как работает интеллект на физическом уровне, прекрасно известно
Раз еще не построили, значит недостаточно известно.
Не понятно, или Вы прикалываетесь, или просто не в курсе.
Я говорю, что не согласен с вашим утверждением. Я думал, это понятно из контекста.
Никто не понимает, как из входа получается выход,
Это неверное утверждение. Какую-то часть понимают, какую-то нет. А специалисты, которых вы назвали, не понимают даже этого. Какие они тогда специалисты?
Они - специалисты по настройке интеллекта.
Так еще нечего настраивать. Чтобы настраивать, надо его сначала построить.
Давайте так. Все открытия в области искусственного интеллекта за последние 60 лет сделаны программистами, и ни одного открытия не сделано психологами. Поэтому считать психологов специалистами в области ИИ нет причин.
Для фильтров можно складывать, если не хочется добавлять лишние условия когда фильтр для этого поля не задан во входных данных, но можно делать и универсальные условия с проверкой на NULL, как вы в процедурах обычно делаете. Но обычно используют Query Builder.
$query = Article::find();
if ($input->title !== null) $query->andWhere(['like', 'title', $input->title]);
if ($input->text !== null) $query->andWhere(['like', 'text', $input->text]);
проблемы с отладкой
Никогда не встречал проблем с отладкой, для всех популярных языков программирования есть пошаговый отладчик.
интерфейсные зависимости переплетаются с логикой бизнес процессов
А зачем вы так пишете? Можно не переплетать, тогда и не будет переплетаться.
нет возможности полноценно отлаживать запросы
Когда из приложения идут только простые SELECT и INSERT, их и не надо отлаживать.
все равно вынуждены проверять как работает запрос напрямую на сервере sql, так как нет гарантии что орм правильно работает
Это, извините, ерунда какая-то. Кто-то может и проверяет, но необходимости в этом нет. Вы же сетевую карту не проверяете, которая вас к базе подключает, а то вдруг она меняет ваш запрос.
дает возможность писать в обычном функциональном стиле с обработкой интерфейсных событий через встроенные процедуры
Ну ок, а зачем?
Другое дело если вы не умеете так строить приложения в БД . в такой двухзвенной архитектуре
Так логически у вас есть то же самое третье звено, только встроенное в БД. Разница только в отсутствии сетевого взаимодействия. Вопрос только в том, зачем его туда встраивать.
написал свою erp систему
Ну так я же не сказал, что написать нельзя. Можно, только дольше и сложнее. Я же вам привел пример с кодом и бизнес-требованиями, напишите свой код, тогда и сравним, как вы умеете строить приложения. Можете сделать только 2 действия "Сохранение товара" и "Отправка на ревью".
Такой своеобразный git
Вот вообще не вижу никаких преимуществ в том, что надо писать свой git.
Я еще не написал про легкую поддержку транзакций в хранимых процедурах.
Ага, вот тут мне человек рассказывал про логику в базе. Оказалось, что в его процедуре без транзакций есть race condition в 2 местах. А явный старт транзакции в базе и в приложении ничем не отличается.
Ну и использовать sql ин'eкции в такой архитектуре практически невозможно.
Да прекрасно можно, если не закрыть все таблицы вьюшками или за правами на строки не уследить. Это от архитектуры не зависит. Там даже инъекция не нужна, пользователь может подключиться через любой клиент со своим паролем и смотреть всё что ему доступно.
Т.е. не обязательно сериализовать данные из БД в объекты, а потом в ответ сервера
Так ORM нужна не для этого. Она нужна для работы с объектами, чтобы указывать типы в аргументах функций, которые с ними работают, и далее для сохранения объектов в базу. Это нужно в первую очередь для изменяющих операций.
Я три дня гналась за вами, чтобы сказать, как вы мне безразличны.
Я не гнался за вами 3 дня. У меня в ленте посты не показываются, я случайно открыл главную Хабра в инкогнито режиме, и ваш пост был второй в ленте. Я увидел вопрос "Что мотивирует людей использовать другие решения?" и решил ответить. Дискуссии на Хабре меня интересуют.
Почему вы думаете, что после этого меня будет интересовать ваше мнение?
Потому что я предполагаю, что вы нормальный человек, и задаете вопросы вида "Что мотивирует людей использовать другие решения?", потому что вас интересует ответ. Вообще сама постановка вопроса означает, что его целевая аудитория те, кому ваши решения неинтересны.
А на зло бабушке отморожу уши.
Нет, никаких проблем от использования других библиотек у меня нет. Это вы предлагаете мне колоться об кактус, делать то, что мне не нравится, непонятно почему.
Но даже её, разумеется, можно улучшить, задавая вопросы
Вот в том и дело, что вы реагируете на вопросы в моем понимании ненормально. Я лучше буду задавать их тем, кто отвечает в моем понимании нормально. Вы можете конечно искать тех, чье понимание нормальности совпадает с вашим, но тогда и не надо удивляться, если их окажется мало.
Выдача своих "очень ценных" советов и оценочных суждений не будучи ни ЦА, ни даже тем, кто попробовал в деле
Так у вас вопрос о том, почему люди ваши проекты не пробуют в деле)) Вот вам и объясняют, что поведение автора это одна из причин.
люди, занимающиеся демагогией Требование сделать ещё больше работы бесплатно - чужое время ведь ничего не стоит
Ага, время написать 46 статей, 47 постов, и кучу комментариев с рекламой своих проектов у вас почему-то нашлось. Это и есть демагогия. Очередное подтверждение, что лучше не иметь с вами никаких дел.
Так же, если результат функции это датасет, то я просто в атрибутах могу задать SQL запрос и не писать реализацию метода. SQLStatement('employee', 'select * from EMPLOYEE order by EMP_NO')]
Ага, а теперь бизнес хочет фильтр на 10 полей. Как вы будете его формировать и помещать в эту строку?
Вот так создается полноценный CRUD к таблице.
Так ORM нужен не для CRUD, а для более сложной логики. Простые CRUD-ы нужны разве что в админках. Допустим, для Update нам надо сделать валидацию 10 полей, вернуть ошибки если есть, получить сущность, проверить ее наличие и возможность операции, если нет или нельзя, показать понятные сообщения пользователю, и только потом обновлять данные. Как это будет выглядеть с SQLStatement?
Стоит ли тут говорить, что это на-порядок быстрее работает, чем ОРМ?
Стоит ли тут говорить, что это на-порядок медленее разрабатывается, чем с ОРМ? Оно не может работать в 10 раз быстрее ORM, потому что сетевой запрос в базу занимает гораздо больше времени, чем обработка в ORM.
Ну а смысл этой трехзавенки тогда, если она усложняет разработку?
Она не усложняет разработку. Это то же самое, что вы делаете на процедурах SQL, только процедуры написаны на более удобном языке. Один из плюсов процедур с приложением на Delphi - не надо перекомпилировать все клиенты при изменении логики в процедуре. Вот сервер в трехзвенке нужен именно для этого. Ну и еще для того, чтобы не давать миллиону пользователей прямой доступ к базе.
Зачем делать сложно когда можно сделать проще, быстрее и меньшим составом разработчиков?
Потому что это с ORM приложение делается проще, быстрее и меньшим составом разработчиков. Для того их и придумали. Если вам проще писать логику на SQL, а не на Delphi, то это зависит от низкоуровневости Delphi, а не от ORM. Я писал на Delphi, именно двухзвенку с логикой в процедурах. На PHP писать гораздо удобнее.
У меня вот есть статья с примером бизнес-требований, там 6 действий, на PHP с ORM их можно сделать часа за 2. Можете попробовать написать и проверить, сколько времени и строк кода это займет на Delphi с SQL процедурами.
переключится автоматом на русский язык если курсор в поле ввода Попробуйте это сделать на любом другом языке кроме С.
Это мало кому нужно, потому что для большинства приложений пользователь может быть из любой страны, а если это внутреннее приложение для сотрудников, то у них обычно и так постоянно включен русский язык.
и все приятные мелочи, которые можно одной строчкой реализовать
Ага, только почему-то вы пишете логику в процедурах, а не в Delphi. Видимо для не-мелочей нужно гораздо больше строк. О том и речь.
У вас SQL упрощает разработку, потому что Delphi это относительно низкоуровневый язык со статической типизацией, и там ORM сложно сделать и использовать, и вообще похоже у вас двухзвенка. А с трехзвенкой есть сервер, где можно использовать язык с динамической типизацией и классами, аналогичный PL SQL, только без его недостатков. И вот там использовать ORM очень удобно.
Давайте я помогу вам правильно процитировать сообщения
Меня не интересует ваше понимание и ваши оправдания. Окружающие сообщения я прочитал до того как писать комментарий. Я привел эти примеры, потому что в моем понимании это некорректное поведение в указанном контексте. Поэтому я буду использовать библиотеки тех авторов, которые в моем понимании ведут себя корректно.
без капли уважения к уже проделанной работе
Меня не интересует ваша работа, я не буду использовать вашу библиотеку только потому что вы ее решили ее написать. У меня есть своя работа, и для нее я буду использовать те библиотеки, с которыми можно быстрее решить нужную задачу. Вы спросили почему люди в продакшене используют и рекомендуют использовать другие библиотеки, а не вашу, получили ответ - потому что людям важна понятная документация и возможность получить нормальный ответ на свой вопрос, а не грубости. Что делать с этой информацией, дело ваше.
И вам об этом писали в комментариях еще 4 года назад. Прежде чем требовать уважения, научитесь сначала уважать других.
Мне нафиг не надо разбираться с вашими заморочками. У меня нет цели изучить ваш полет мысли, у меня есть цель сделать задачу. Я буду использовать те библиотеки, авторы которых пишут нормальную документацию, нормально отвечают на вопросы и нормально реагируют на указание недостатков.
Но давайте будем честными. Именно жесткие и требовательные руководители чаще всего добиваются выдающихся результатов.
Давайте. Именно жесткие и требовательные руководители реже всего добиваются выдающихся результатов.
Когда честная обратная связь и ожидание качественной сделанной работы стали чем-то плохим?
Когда вы думаете, что это честная обратная связь и ожидание качественной сделанной работы, а на самом деле это не честная обратная связь и необоснованное ожидание слишком большого качества за те деньги, которые вы платите.
Я постоянно с этим сталкиваюсь. Даешь человеку честную обратную связь – всё, ты враг. Начинаются обиды, оправдания, поиск виноватых. Хотя единственная цель критики — сделать лучше.
Может быть дело в том, как именно вы даете обратную связь? Вы в курсе, что люди не умеют читать мысли, и слышат только слова, которые вы говорите? И понять их они могут не так, как вы задумывали. Нормальный руководитель должен это учитывать.
Если ты требуешь от людей результатов – ты «токсичный».
Если вам разные люди говорят, что вы токсичный, значит вы токсичный. Потому что другим они так не говорят.
«Давай подтянем этот навык»
Просто так, забесплатно?
«Твоя работа может быть лучше»
Просто так, забесплатно?
Компании, активно использующие честную обратную связь Сотрудники, регулярно получающие конструктивную критику
Логическая манипуляция. Мы еще не доказали, что ваша обратная связь честная, а критика конструктивная. Так как примеров вы не привели, то есть вероятность, что вы сами понимаете, что ведете себя некорректно.
Во-первых, "основная цель" и "устройство" - это разное.
Я и не сказал, что оно одинаковое. Они напрямую связаны, изменяя внутреннее устройство можно изменять возможности механизма, приближая их к цели.
Во-вторых, я вообще не говорил про цель разработки ИИ.
Вот поэтому ваша аналогия и неправильная. Специалист в вопросе это тот, кто знает, как достичь цели.
Речь идёт про AGI, который мыслит, а разработчики - они про алгоритмы, а не про мыслить.
А вы думаете, естественный интеллект работает на неведомой магии? Естественный интеллект состоит из молекул, их взаимодействие можно описать алгоритмом, значит и мышление этого интеллекта можно описать алгоритмом.
В третьих, никто толком не понимает алгоритмику внутри даже нынешних сеток.
Алгоритм программы изложен в исходном коде. Он не магически появился из ниоткуда, а его написали разработчики. Раз написали, значит понимают достаточно, чтобы это сделать. А специалисты, которых вы назвали, так сделать не могут. Назовите хоть одно достижение в области построения искусственного интеллекта за последние 60 лет, сделанное психологами. Его нет. Поэтому и считать их специалистами в этой области нет причин.
Специалисты по разработке нейросетей не являются специалистами по разуму.
Являются. Потому что основная цель в ИИ это обработка информации аналогично человеку, a программисты это специалисты в создании алгоритмов обработки информации.
Специалистами по разуму на данный момент являются психологи
Нет. Это специалисты по управлению чайником. Они умеют хорошо управлять чайником, но понятия не имеют, как его построить.
Ну так я ее написал как раз потому, что вы говорите не про "квантовых физиков", а про "разработчиков электрических приборов". И в качестве специалистов приводите людей, которые наблюдают лишь внешние проявления чайника, и аналогичные приборы никогда не разрабатывали.
"Меня не интересует мнение инженеров, которые разрабатывают электрические приборы, насчет возможного устройства импортного электрического чайника, меня бы больше интересовало мнение домохозяйки, которая непосредственно им управляет с помощью 2 кнопок"
В этом ведь и заключается бонус от ООП, чтобы данные и действия над данными были ассоциированы и лежали в одном месте.
Ага, в этом и заключается распространенное заблуждение. Бизнес-логика это не поведение сущности, не действия над полями сущности, и не детали ее реализации. По той простой причине, что в одном бизнес-процессе может участвовать несколько сущностей. Поэтому она должна быть не в объекте сущности, а где-то снаружи нее в другом объекте. Объект участвует в некотором бизнес-процессе, а не задает его. Распространенный пример - перевод с аккаунта на аккаунт, его даже DDD рекомендует делать сервисом. И принцип не меняется, если в некотором процессе участвует одна сущность, а не две. Сегодня одна, завтра бизнес захочет три. С логикой в сущностях придется всё переписывать.
Другой пример: "После сохранения заказа в системе нужно отправить email пользователю с информацией о заказе". Тут нет действий над полями сущности, но реализация этих бизнес-требований это бизнес-логика.
В конце концов никто не заставляет вас писать экземплярные методы, можете использовать статику для работы с коллекциями.
Куча статических методов это ужасная архитектура. Это само по себе говорит, что вы поместили их не в тот объект, к которому они принадлежат. Об этом же говорит и копипаста IData в каждом методе. Вы же говорите, что действия должны быть ассоциированы с данными, а статические методы с нестатическими полями объекта не могут работать, значит не ассоциированы с ними, они могут обращаться только к набору статических полей. Вот этот набор статических полей и методов можно выделить в отдельный объект. Это и будет сервис.
проверить изменения домена на ревью сильно проще
Ну я же вам объясняю, вот проверили вы изменения домена на ревью, а контроллер не проверили, а программист там написал SQL-запросы с UPDATE. Проверять в любом случае надо весь код.
Да и изменение существующего бизнес правила будет проще.
Я приводил пример DeleteRange в сервисе. Почему оно проще, если код абсолютно одинаковый?
второй сервис Смысл повторять из раза в раз одни и те же проверки в каждом сервисе?
Нету смысла. Поэтому в таких случаях делают один сервис, зачем их два-то делать?) Вы же не делаете две сущности.
В первом вы описали логику что при удалении поступления нужно проверить хватает ли товаров на складе, а во втором сервисе при создании объекта забыли. В моем случае это забыть невозможно, в самом товаре на складе свойство количество имеет приватный сеттер
Ну как это невозможно. Статические методы имеют доступ к приватным полям, берем и меняем напрямую.
class Product {
public static void cancelReceipt(List<ProductRecord> receiptProducts) {
foreach (var productRecord in receiptProducts) {
var product = this.repository.findOne(productRecord.id);
product.quantity -= productRecord.quantity;
}
}
}
и есть 2 публичных метода добавить товар на склад или убрать его, в которых есть все необходимые проверки
Ну так и с логикой в сервисе есть те же самые 2 метода, в которых есть все необходимые проверки.
class StorageService {
public void receipt(ReceiptParamsDTO receiptParams) {
... addProduct();
}
public void shipment(ShipmentParamsDTO receiptParams) {
... removeProduct();
}
public void cancelReceipt(Document receiptDocument) {
... removeProduct();
}
public void cancelShipment(Document shipmentDocument) {
... addProduct();
}
private void addProduct(...) {
...
}
private void removeProduct(...) {
var resultQuantity = ...;
if (resultQuantity < 0) throw new RuntimeException(...);
...
}
}
Более того, в случае поступлений и отгрузок надо не только обновлять остатки, а еще и сохранять документы в системе, с информацией о компании, которая получает товар, и т.д. А Document это другой агрегат, и Product не является его частью, поэтому по DDD для этой логики требуется доменный сервис, так же как для перевода с аккаунта на аккаунт.
В данном случае все эти статические методы являются чистыми.
Неважно, это все равно скрытые зависимости. Чтобы узнать, что класс с ними работает, надо проверить всю реализацию.
пока статический метод не меняет никакого глобального состояния он абсолютно не предоставляет никакой угрозы.
А это неважно, важно что эта якобы чистая архитектура не умеет работать с зависимостями, и приходится использовать глобальные переменные. Как вы в этом классе будете использовать статический метод, который меняет глобальное состояние? Так же через обращение к глобальной переменной.
Я согласен, простые зависимости, которые не надо мокать в тестах, можно делать статическими методами, но с сервисом хотя бы выбор есть. Если она из простой превратится в сложную, можно будет пробросить ее в конструктор.
А вот например такой код вас тоже смущает?
Немного. Но там хотя бы общеизвестные математические операции, которые зависят только от аргументов, а DateTime.UtcNow и Guid.NewGuid() это ввод-вывод.
order.Customer.Serialize(); Такой код тоже плохой?
Да. Программисту, который этот код не писал, будет гораздо понятнее, если вы сделаете отдельный сервис сериализации и явно его пробросите в вызывающий код.
когда программисты напишут вам прямо в контроллере доменную логику?
Ну так это вопрос код-ревью, а не расположения логики. С логикой в сущностях тоже можно написать часть доменной логики в контроллерах.
но будет сервис на другую сущность и в нем забыв о каком то бизнес правиле изменят первую сущность
Такой код там может появиться только если есть бизнес-требование менять первую сущность. А бизнес свои правила знает сам. Какие проверки он сказал, такие и делаем. Не сказал, не делаем. Хотя можем уточнить.
А вот за то что ошибся и забыл бизнес-правило
Что значит "забыл бизнес-правило"? Правила идут от бизнеса и указаны в задаче на добавление нового функционала. Как он сказал так и делаем, неважно, какие правила были для другого функционала. Бизнес со своими правилами сам разберется. Я же говорю, в сервисах новый код для изменения сущности пишется ровно в тех же случаях, когда с логикой в сущностях надо добавлять в сущность новый метод. И нужные проверки можно пропустить в обоих случаях.
для чего тогда вообще на уровне сценария получать сущности из репозитория
Я не очень понял вопрос, я обычно получаю сущность в контроллере, потому что для нее надо проверить 404 и 403, а возврат этих статусов ответственность контроллера. Можно делать application service и загружать сущность по id там, видимо вы его имеете в виду, но тогда он будет имитировать контроллер, и надо будет использовать исключения. Мне это кажется ненужным усложнением.
не проще ли вообще закрыть доступ к сущностям и наружу светить только методами сервисов
Куда наружу-то, в контроллер? С логикой в сервисах так и делают, метод контроллера вызывает метод сервиса. Любые изменения сущности только через сервис.
Я же привел пример с динамическими объектами. Ссылка на динамический объект хранится в локальной переменной, у которой есть область видимости.
А почему нельзя решить это подсчетом ссылок при выходе из области видимости или при записи в ссылочное поле?
То есть это тоже расходы в рантайме, но это не совсем gc. Количество ссылочных полей в классе известно при компиляции, компилятор может подготовить нужные инструкции.
Всё в компайл-тайме и не проверишь, количество ссылок может зависеть от входных данных в рантайме.
Ну я вам так и сказал, вы путаете инженеров с домохозяйками. Домохозяйка не знает, как работает утюг и как его построить.
Нет, не понимают как раз как построить. Использовать ИИ хотят так же, как ЕИ - сказал задачу словами, он понял и сделал как нужно.
Мы говорим не о приборе, который измеряет параметры интеллекта, а о самом интеллекте.
"Специалисты, которые строят интеллект" в вашей аналогии будут "специалисты, которые воспроизводят в лаборатории красное смещение". Их мнение в изучении этого вопроса очень даже релевантно.
Раз еще не построили, значит недостаточно известно.
Я говорю, что не согласен с вашим утверждением. Я думал, это понятно из контекста.
Это неверное утверждение. Какую-то часть понимают, какую-то нет.
А специалисты, которых вы назвали, не понимают даже этого. Какие они тогда специалисты?
Так еще нечего настраивать. Чтобы настраивать, надо его сначала построить.
Давайте так. Все открытия в области искусственного интеллекта за последние 60 лет сделаны программистами, и ни одного открытия не сделано психологами. Поэтому считать психологов специалистами в области ИИ нет причин.
Зачем? Не нужно там ничего складывать, даже без ORM.
Для фильтров можно складывать, если не хочется добавлять лишние условия когда фильтр для этого поля не задан во входных данных, но можно делать и универсальные условия с проверкой на NULL, как вы в процедурах обычно делаете.
Но обычно используют Query Builder.
Никогда не встречал проблем с отладкой, для всех популярных языков программирования есть пошаговый отладчик.
А зачем вы так пишете? Можно не переплетать, тогда и не будет переплетаться.
Когда из приложения идут только простые SELECT и INSERT, их и не надо отлаживать.
Это, извините, ерунда какая-то. Кто-то может и проверяет, но необходимости в этом нет. Вы же сетевую карту не проверяете, которая вас к базе подключает, а то вдруг она меняет ваш запрос.
Ну ок, а зачем?
Так логически у вас есть то же самое третье звено, только встроенное в БД. Разница только в отсутствии сетевого взаимодействия. Вопрос только в том, зачем его туда встраивать.
Ну так я же не сказал, что написать нельзя. Можно, только дольше и сложнее.
Я же вам привел пример с кодом и бизнес-требованиями, напишите свой код, тогда и сравним, как вы умеете строить приложения. Можете сделать только 2 действия "Сохранение товара" и "Отправка на ревью".
Вот вообще не вижу никаких преимуществ в том, что надо писать свой git.
Ага, вот тут мне человек рассказывал про логику в базе. Оказалось, что в его процедуре без транзакций есть race condition в 2 местах.
А явный старт транзакции в базе и в приложении ничем не отличается.
Да прекрасно можно, если не закрыть все таблицы вьюшками или за правами на строки не уследить. Это от архитектуры не зависит.
Там даже инъекция не нужна, пользователь может подключиться через любой клиент со своим паролем и смотреть всё что ему доступно.
А с чего вы взяли, что его сотрудники действительно не выполняют поставленные задачи в срок и не соблюдают исполнительскую дисциплину?
А с чего вы взяли, что его сотрудники действительно проявляют лень, раздолбайство и "особое свое мнение" которое идет вразрез с поставленными целями?
Так ORM нужна не для этого. Она нужна для работы с объектами, чтобы указывать типы в аргументах функций, которые с ними работают, и далее для сохранения объектов в базу. Это нужно в первую очередь для изменяющих операций.
Я не гнался за вами 3 дня. У меня в ленте посты не показываются, я случайно открыл главную Хабра в инкогнито режиме, и ваш пост был второй в ленте. Я увидел вопрос "Что мотивирует людей использовать другие решения?" и решил ответить. Дискуссии на Хабре меня интересуют.
Потому что я предполагаю, что вы нормальный человек, и задаете вопросы вида "Что мотивирует людей использовать другие решения?", потому что вас интересует ответ.
Вообще сама постановка вопроса означает, что его целевая аудитория те, кому ваши решения неинтересны.
Нет, никаких проблем от использования других библиотек у меня нет. Это вы предлагаете мне колоться об кактус, делать то, что мне не нравится, непонятно почему.
Вот в том и дело, что вы реагируете на вопросы в моем понимании ненормально. Я лучше буду задавать их тем, кто отвечает в моем понимании нормально. Вы можете конечно искать тех, чье понимание нормальности совпадает с вашим, но тогда и не надо удивляться, если их окажется мало.
Так у вас вопрос о том, почему люди ваши проекты не пробуют в деле)) Вот вам и объясняют, что поведение автора это одна из причин.
Ага, время написать 46 статей, 47 постов, и кучу комментариев с рекламой своих проектов у вас почему-то нашлось. Это и есть демагогия. Очередное подтверждение, что лучше не иметь с вами никаких дел.
Выглядит неплохо, согласен.
Ага, а теперь бизнес хочет фильтр на 10 полей. Как вы будете его формировать и помещать в эту строку?
Так ORM нужен не для CRUD, а для более сложной логики. Простые CRUD-ы нужны разве что в админках.
Допустим, для Update нам надо сделать валидацию 10 полей, вернуть ошибки если есть, получить сущность, проверить ее наличие и возможность операции, если нет или нельзя, показать понятные сообщения пользователю, и только потом обновлять данные.
Как это будет выглядеть с SQLStatement?
Стоит ли тут говорить, что это на-порядок медленее разрабатывается, чем с ОРМ?
Оно не может работать в 10 раз быстрее ORM, потому что сетевой запрос в базу занимает гораздо больше времени, чем обработка в ORM.
Она не усложняет разработку. Это то же самое, что вы делаете на процедурах SQL, только процедуры написаны на более удобном языке. Один из плюсов процедур с приложением на Delphi - не надо перекомпилировать все клиенты при изменении логики в процедуре. Вот сервер в трехзвенке нужен именно для этого. Ну и еще для того, чтобы не давать миллиону пользователей прямой доступ к базе.
Потому что это с ORM приложение делается проще, быстрее и меньшим составом разработчиков. Для того их и придумали. Если вам проще писать логику на SQL, а не на Delphi, то это зависит от низкоуровневости Delphi, а не от ORM. Я писал на Delphi, именно двухзвенку с логикой в процедурах. На PHP писать гораздо удобнее.
У меня вот есть статья с примером бизнес-требований, там 6 действий, на PHP с ORM их можно сделать часа за 2. Можете попробовать написать и проверить, сколько времени и строк кода это займет на Delphi с SQL процедурами.
Это мало кому нужно, потому что для большинства приложений пользователь может быть из любой страны, а если это внутреннее приложение для сотрудников, то у них обычно и так постоянно включен русский язык.
Ага, только почему-то вы пишете логику в процедурах, а не в Delphi. Видимо для не-мелочей нужно гораздо больше строк. О том и речь.
У вас SQL упрощает разработку, потому что Delphi это относительно низкоуровневый язык со статической типизацией, и там ORM сложно сделать и использовать, и вообще похоже у вас двухзвенка. А с трехзвенкой есть сервер, где можно использовать язык с динамической типизацией и классами, аналогичный PL SQL, только без его недостатков. И вот там использовать ORM очень удобно.
Меня не интересует ваше понимание и ваши оправдания. Окружающие сообщения я прочитал до того как писать комментарий. Я привел эти примеры, потому что в моем понимании это некорректное поведение в указанном контексте. Поэтому я буду использовать библиотеки тех авторов, которые в моем понимании ведут себя корректно.
Меня не интересует ваша работа, я не буду использовать вашу библиотеку только потому что вы ее решили ее написать. У меня есть своя работа, и для нее я буду использовать те библиотеки, с которыми можно быстрее решить нужную задачу. Вы спросили почему люди в продакшене используют и рекомендуют использовать другие библиотеки, а не вашу, получили ответ - потому что людям важна понятная документация и возможность получить нормальный ответ на свой вопрос, а не грубости. Что делать с этой информацией, дело ваше.
И вам об этом писали в комментариях еще 4 года назад. Прежде чем требовать уважения, научитесь сначала уважать других.
Я бы принципиально не стал использовать в продакшене ваши проекты из-за вашего отношения к пользователям и высокомерной манеры общения.
https://habr.com/ru/articles/740240/comments/#comment_25623104
"Если вы не заинтересованы в поиске, а выискиваете повод уйти, то вам действительно лучше уйти."
Вы сначала заявляете "Не нравится, валите, ничего менять не буду", а потом удивляетесь, почему все свалили.
Мне пофиг, что вы сказали это про ваш сайт знакомств, я вижу, что с другими проектами у вас такое же поведение.
https://habr.com/ru/articles/884208/comments/#comment_28003268
"Ой, так лень читать ваш лонгрид с какими-то мутными скринами...Так и не понял, чего вам не хватило в документации."
https://habr.com/ru/articles/804193/comments/#comment_26697113
"А можно пример? - Нельзя. Не ленитесь учиться."
https://habr.com/ru/articles/491120/#comment_21360066
"Я трачу на этот проект своё личное время не для того, чтобы помочь вам зарабатывать на ваших проектах больше денег."
Мне нафиг не надо разбираться с вашими заморочками. У меня нет цели изучить ваш полет мысли, у меня есть цель сделать задачу. Я буду использовать те библиотеки, авторы которых пишут нормальную документацию, нормально отвечают на вопросы и нормально реагируют на указание недостатков.
Давайте. Именно жесткие и требовательные руководители реже всего добиваются выдающихся результатов.
Когда вы думаете, что это честная обратная связь и ожидание качественной сделанной работы, а на самом деле это не честная обратная связь и необоснованное ожидание слишком большого качества за те деньги, которые вы платите.
Может быть дело в том, как именно вы даете обратную связь? Вы в курсе, что люди не умеют читать мысли, и слышат только слова, которые вы говорите? И понять их они могут не так, как вы задумывали. Нормальный руководитель должен это учитывать.
Если вам разные люди говорят, что вы токсичный, значит вы токсичный. Потому что другим они так не говорят.
Просто так, забесплатно?
Просто так, забесплатно?
Логическая манипуляция. Мы еще не доказали, что ваша обратная связь честная, а критика конструктивная. Так как примеров вы не привели, то есть вероятность, что вы сами понимаете, что ведете себя некорректно.
Я и не сказал, что оно одинаковое. Они напрямую связаны, изменяя внутреннее устройство можно изменять возможности механизма, приближая их к цели.
Вот поэтому ваша аналогия и неправильная. Специалист в вопросе это тот, кто знает, как достичь цели.
А вы думаете, естественный интеллект работает на неведомой магии?
Естественный интеллект состоит из молекул, их взаимодействие можно описать алгоритмом, значит и мышление этого интеллекта можно описать алгоритмом.
Алгоритм программы изложен в исходном коде. Он не магически появился из ниоткуда, а его написали разработчики. Раз написали, значит понимают достаточно, чтобы это сделать. А специалисты, которых вы назвали, так сделать не могут. Назовите хоть одно достижение в области построения искусственного интеллекта за последние 60 лет, сделанное психологами. Его нет. Поэтому и считать их специалистами в этой области нет причин.
Я понял и говорю, что она неправильная.
Являются. Потому что основная цель в ИИ это обработка информации аналогично человеку, a программисты это специалисты в создании алгоритмов обработки информации.
Нет. Это специалисты по управлению чайником. Они умеют хорошо управлять чайником, но понятия не имеют, как его построить.
Ну так я ее написал как раз потому, что вы говорите не про "квантовых физиков", а про "разработчиков электрических приборов". И в качестве специалистов приводите людей, которые наблюдают лишь внешние проявления чайника, и аналогичные приборы никогда не разрабатывали.
"Меня не интересует мнение инженеров, которые разрабатывают электрические приборы, насчет возможного устройства импортного электрического чайника, меня бы больше интересовало мнение домохозяйки, которая непосредственно им управляет с помощью 2 кнопок"
Ага, в этом и заключается распространенное заблуждение. Бизнес-логика это не поведение сущности, не действия над полями сущности, и не детали ее реализации. По той простой причине, что в одном бизнес-процессе может участвовать несколько сущностей. Поэтому она должна быть не в объекте сущности, а где-то снаружи нее в другом объекте. Объект участвует в некотором бизнес-процессе, а не задает его. Распространенный пример - перевод с аккаунта на аккаунт, его даже DDD рекомендует делать сервисом. И принцип не меняется, если в некотором процессе участвует одна сущность, а не две. Сегодня одна, завтра бизнес захочет три. С логикой в сущностях придется всё переписывать.
Другой пример: "После сохранения заказа в системе нужно отправить email пользователю с информацией о заказе". Тут нет действий над полями сущности, но реализация этих бизнес-требований это бизнес-логика.
Куча статических методов это ужасная архитектура. Это само по себе говорит, что вы поместили их не в тот объект, к которому они принадлежат. Об этом же говорит и копипаста IData в каждом методе.
Вы же говорите, что действия должны быть ассоциированы с данными, а статические методы с нестатическими полями объекта не могут работать, значит не ассоциированы с ними, они могут обращаться только к набору статических полей. Вот этот набор статических полей и методов можно выделить в отдельный объект. Это и будет сервис.
Ну я же вам объясняю, вот проверили вы изменения домена на ревью, а контроллер не проверили, а программист там написал SQL-запросы с UPDATE. Проверять в любом случае надо весь код.
Я приводил пример DeleteRange в сервисе. Почему оно проще, если код абсолютно одинаковый?
Нету смысла. Поэтому в таких случаях делают один сервис, зачем их два-то делать?) Вы же не делаете две сущности.
Ну как это невозможно. Статические методы имеют доступ к приватным полям, берем и меняем напрямую.
Ну так и с логикой в сервисе есть те же самые 2 метода, в которых есть все необходимые проверки.
Более того, в случае поступлений и отгрузок надо не только обновлять остатки, а еще и сохранять документы в системе, с информацией о компании, которая получает товар, и т.д. А Document это другой агрегат, и Product не является его частью, поэтому по DDD для этой логики требуется доменный сервис, так же как для перевода с аккаунта на аккаунт.
Неважно, это все равно скрытые зависимости. Чтобы узнать, что класс с ними работает, надо проверить всю реализацию.
А это неважно, важно что эта якобы чистая архитектура не умеет работать с зависимостями, и приходится использовать глобальные переменные. Как вы в этом классе будете использовать статический метод, который меняет глобальное состояние? Так же через обращение к глобальной переменной.
Я согласен, простые зависимости, которые не надо мокать в тестах, можно делать статическими методами, но с сервисом хотя бы выбор есть. Если она из простой превратится в сложную, можно будет пробросить ее в конструктор.
Немного. Но там хотя бы общеизвестные математические операции, которые зависят только от аргументов, а DateTime.UtcNow и Guid.NewGuid() это ввод-вывод.
Да. Программисту, который этот код не писал, будет гораздо понятнее, если вы сделаете отдельный сервис сериализации и явно его пробросите в вызывающий код.
Ну так это вопрос код-ревью, а не расположения логики. С логикой в сущностях тоже можно написать часть доменной логики в контроллерах.
Такой код там может появиться только если есть бизнес-требование менять первую сущность. А бизнес свои правила знает сам. Какие проверки он сказал, такие и делаем. Не сказал, не делаем. Хотя можем уточнить.
Что значит "забыл бизнес-правило"? Правила идут от бизнеса и указаны в задаче на добавление нового функционала. Как он сказал так и делаем, неважно, какие правила были для другого функционала. Бизнес со своими правилами сам разберется.
Я же говорю, в сервисах новый код для изменения сущности пишется ровно в тех же случаях, когда с логикой в сущностях надо добавлять в сущность новый метод. И нужные проверки можно пропустить в обоих случаях.
Я не очень понял вопрос, я обычно получаю сущность в контроллере, потому что для нее надо проверить 404 и 403, а возврат этих статусов ответственность контроллера. Можно делать application service и загружать сущность по id там, видимо вы его имеете в виду, но тогда он будет имитировать контроллер, и надо будет использовать исключения. Мне это кажется ненужным усложнением.
Куда наружу-то, в контроллер? С логикой в сервисах так и делают, метод контроллера вызывает метод сервиса. Любые изменения сущности только через сервис.