В умный объект или в dto

эм... ну dto ж тебе потом надо как-то гдето юзать

логика где будет?

данные есть, дальше куда?

row data gateway?

для этого active record больше подходит

мэпить на настоящие сущности - ну... опять же дополнительный жирный слой

stateless сервисы менеджеры? данные отдельно, процедуры отдельно? Ну такое...

эм... ну dto ж тебе потом надо как-то гдето юзать

em->flush ()

анемичная модель короч

Есть сущности, они по какой-то причине не влазят сами в доктрину

логика то где будет?)

Нет разницы мапить их на дао или на дто

вот... есть у тебя Order сущность

Дто, которые поползут в доктрину

где будет подсчет стоимость заказа?

у нас Order тупо dto, проекция таблички, так?

Нее

OrderGateway

Есть order сущность

А есть дто для доктрины

Или дао от элоквента

И вот это без разницы

Или дао от элоквента

чта?

Ладно, позже врублюсь обратно

что за dao от элоквента?

там есть квери билдер... и есть active record.... для dao малова-то а для row data gateway хватает

короч да, завтра)

а маппить в доктрину в этом случае легко? вопрос в другой чатик должен быть, но он мелкий)

возвращаясь к вопросу о зависимостях

кейсов не было?

там есть квери билдер... и есть active record.... для dao малова-то а для row data gateway хватает

Я про active record

возвращаясь к вопросу о зависимостях

?

Инъектить в сущность не надо, в методы дабл диспатч можно/нужно

Я про active record

а причем тут dao?

а причем тут dao?

Ну юзать его как дао

Ну юзать его как дао

скорее как row data gateway

dao чуть поприкольнее

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

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

пример?

Читаю с http://codersatwork.com/ интересно чем они руководствовались

Привет всем, у меня будет семинар через час, о декораторах в ООП. Кому интересно, приходите онлайн: https://www.youtube.com/watch?v=LPLqLaSwSsI

привет, я тебя видел на стикерах? так что буду на семинаре)

А набрасывать как-то можно в процессе?

Привет всем, у меня будет семинар через час, о декораторах в ООП. Кому интересно, приходите онлайн: https://www.youtube.com/watch?v=LPLqLaSwSsI

???

А набрасывать как-то можно в процессе?

да конечно, прямо в коментах на ютубе

@yegor256 пропустил трансляцию, но спс, посмотрю)

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

False. Правильная фраза такая: "Проблема ЛЮБЫХ языков в том, что они тянут за собой всё, что с ними связано. Вы хотели банан, а получили обезьяну, его держащую, и еще все джунгли в придачу."

False. Правильная фраза такая: "Проблема ЛЮБЫХ языков в том, что они тянут за собой всё, что с ними связано. Вы хотели банан, а получили обезьяну, его держащую, и еще все джунгли в придачу."

Проблема?

Проблема?

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

Возьмем например сишечку, поясните в чем там проблема, кому что тянуть надо?

хз вообще о чем речь

проблемы какие-то, обезъяны... слишком стремная метафора

Возьмем например сишечку, поясните в чем там проблема, кому что тянуть надо?

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

В том же NodeJS. Если вы хотите использовать только одну функцию из некоторого пакета, то всё равно нужно будет установить целый пакет и все его зависимости.

В том же NodeJS. Если вы хотите использовать только одну функцию из некоторого пакета, то всё равно нужно будет установить целый пакет и все его зависимости.

Tree Shaking и DCE давно уже есть в мире JS.

> Хотя конечно можно скомпилировать только, то что нужно из исходников, но не факт, что это удастся или что это удастся легко. Webpack в JS это без проблем делает.

False. Правильная фраза такая: "Проблема ЛЮБЫХ языков в том, что они тянут за собой всё, что с ними связано. Вы хотели банан, а получили обезьяну, его держащую, и еще все джунгли в придачу."

хренасе ты умные вещи выдаешь

Ну это не панацея, так как для такого динамического языка как JS невозможно точно на время "компиляции" установить взаимосвязи.

ERROR: S client not available

Esm как бы

Статический

и опять же, используют ли webpack для сборки бэкенда?

и опять же, используют ли webpack для сборки бэкенда?

Это не оч

и опять же, используют ли webpack для сборки бэкенда?

А в чём проблема его и для backend использовать?

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

Везде так

Везде так

Именно об этом я и говорю.

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

вот по этому придумали такую штуку как сегрегация интерфейсов. А так все ненужное обычно выбрасывается во время компиляции проекта

и в целом не засоряет ничего

А в чём проблема его и для backend использовать?

немного излишнее действие

немного излишнее действие

ты про разработку бэкэнда для ноды? тебя смущает что не используемый код будет грузиться в память?

Именно об этом я и говорю.

На момент установки библиотеки не так легко определить pm'у какие функции тебе нужны. Его надо для начала к тебе ментальной связью подключить

Так а почеиу это проблема?

import {someFunction} from 'library';

ты про разработку бэкэнда для ноды? тебя смущает что не используемый код будет грузиться в память?

Не будет

ну я как бы о том же

ты про разработку бэкэнда для ноды? тебя смущает что не используемый код будет грузиться в память?

меня смущает Webpack для сборки бэкенда, когда можно без него

проблемы вообще нет

проблемы вообще нет

+

меня смущает Webpack для сборки бэкенда, когда можно без него

тебе не нужен webpack для сборки бэкэнда

Так а почеиу это проблема?

Ну это не то чтобы проблема, просто небольшая неприятность.

webpack для сборки фронтэнда применяют что бы в итоговых файликах для сборки было ровно то что используется для оптимизации трафика

Какая разница в 2017 году, какой размер у бандла (исключение — клиент-сайд)? Ну будет весить конечный серверный JS бандл проекта 2.5 мегабайта, а не 7.5. Потребление RAM не увеличится.

Ну это не то чтобы проблема, просто небольшая неприятность.

нет никакой неприятности. Для бэкэнда тебе не нужны такого рода оптимизации, их за тебя делает VM

не используемый код не используется

Вот именно)

потому проблему я вижу только одну - непонимание того как использутся инструменты. Это приводит к определенным предположениям и теориям. А когда у тебя рождается предположение или теория ты должен приложить все силы к тому что бы ее опровергнуть.

эксперемент