Как вы относитесь к названию функции, где фигурирует 'By'? Например allOrdersByUser(User $user) У нас нету строго правила по этому поводу и люди просто иногда пишут by, а иногда не пишут. Мне кажется странным дублировать User и в названии, и во входных параметрах. То есть и так понятно, что по юзеру.

как жаль, что нет перегрузки getAllOrdersBy(User $user) getAllOrdersBy(Item $item)

ну... а оно там точно требуется? :)

меня так бесят названия функции на пол экрана из-за всяких by

как жаль, что нет перегрузки getAllOrdersBy(User $user) getAllOrdersBy(Item $item)

?

меня так бесят названия функции на пол экрана из-за всяких by

нет проблемы в длинных названиях.

/

Как вы относитесь к названию функции, где фигурирует 'By'? Например allOrdersByUser(User $user) У нас нету строго правила по этому поводу и люди просто иногда пишут by, а иногда не пишут. Мне кажется странным дублировать User и в названии, и во входных параметрах. То есть и так понятно, что по юзеру.

Имхо, getOrders(User $user) - все заказы юзера, даже all не стоит добавлять. То, что не "all" нужно уточнять до конкретных целей. Например: getActiveOrders(User $user)

как жаль, что нет перегрузки getAllOrdersBy(User $user) getAllOrdersBy(Item $item)

Используй критерии)

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

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

забаньте этого уже...

он во всех чатах уже спросил

он во всех чатах уже спросил

и?

ты читай про что чат прежде чем вопрос то задавать

суббота сегодня :)

уже суббота

доброе утро :)

это новый паттерн в вашем недоязыке?

На любой язык без синтаксических макросов.

это новый паттерн в вашем недоязыке?

А в вашем недоязыке это уже успело наскучить?

А в вашем недоязыке это уже успело наскучить?

у нас недоязыков нет.

у нас недоязыков нет.

От гипертрофии самооценки он не защитил

От гипертрофии самооценки он не защитил

просто не у всех путь развития - Turbo Pascal, Delphi и 1C

Это не повод называть остальных недоязыками

зачем стараться писать буквы если это все равно потрут...

Это не повод называть остальных недоязыками

назвать ваш Turbo Cobol сверхязыком было бы лицемерием

Дайте мне обычный язык

Пацан поставил надстройку 1C.СВЕРХЧСВ а вы просто ему завидуете

Дайте мне обычный язык

Common Lisp

Спасибо

?

Common Lisp

может все таки Haskell?

турбо хаскель

может все таки Haskell?

А вы продаёте или покупаете

А вы продаёте или покупаете

я работаю по тех заданию

турбо хаскель

Common

...

Ваш ответ не оч, попробуйте еще раз

а правильно ли я понимаю, что когда мне нужно добавить DO в базу, я делаю частично инициализированный DO (без уставновленного id, например) передаю его в registry.store(), а он, в свою очередь, передаёт этот DO DataMapper'у (или как его принято называть?) который сохраняет DO в базе и устанавливает id и не нужно передавать DO напрямую в DataMapper из сервисов

uuid

а правильно ли я понимаю, что когда мне нужно добавить DO в базу, я делаю частично инициализированный DO (без уставновленного id, например) передаю его в registry.store(), а он, в свою очередь, передаёт этот DO DataMapper'у (или как его принято называть?) который сохраняет DO в базе и устанавливает id и не нужно передавать DO напрямую в DataMapper из сервисов

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

а почему uuid, а не автоинкрементальный id?

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

ну он же просто объект, а не ActiveRecord

do ж как раз про то, чтобы все это в одно место запихать, типа как active record, но только в базу умеет

а почему uuid, а не автоинкрементальный id?

Потому что для инкрементального надо в базу сходить

ну он же просто объект, а не ActiveRecord

Active record так-то тоже просто объект, у которого есть ссылка на connection/transaction :)

ну я почему-то хочу обьект, который ничего не знает о способе своего хранения и отвязан от схемы базы данных. И lazy load мне пока не нужен. поэтому и цеочка do - registry - mapper - бд

ну я почему-то хочу обьект, который ничего не знает о способе своего хранения и отвязан от схемы базы данных. И lazy load мне пока не нужен. поэтому и цеочка do - registry - mapper - бд

Do - domain object? Тогда делайте корень агрегата и репозиторий

Или do это dao?

Я говорил про второе

Do - domain object? Тогда делайте корень агрегата и репозиторий

DO - domain object

Дурные термины(

Ну в общем стоит стремиться к тому, чтобы никто кроме самого объекта ничего не менял в нем и для id можно юзать uuid

Но конкретно в случае с id и сценариями, где все в одной транзакции можно использовать автоинкремент

а когда я добавляю новый DO и хочу его сохранить, я делаю это через registry или напрямую через mapper?

ERROR: S client not available

через mapper — некрасивая зависимость получается

Новый созданный объект обычно добавляется в некую коллекцию объектов

Которая может быть персистентной разными способами

В ddd такие do называются корнями агрегата, а коллекции называются репозиториями

Которая может быть персистентной разными способами

Коллекция может использовать какую-то orm, например data mapper(hibernate/doctrine)

получается, всё-таки в репозиторий правильно. и остальной домен не должен ничего знать про orm, которую использует репозиторий

Или она может подписываться на события объекта и персистить только их

Или искать/создавать dao для объекта и через него объект сохранять

Новый объект — это кстати вообще отдельная категория сущностей

получается, всё-таки в репозиторий правильно. и остальной домен не должен ничего знать про orm, которую использует репозиторий

Правильно плохое слово )

Правильно плохое слово )

более красиво?

Плохо тоже плохое слово

более красиво?

Может сработать в большом числе случаев )

Ну в общем стоит стремиться к тому, чтобы никто кроме самого объекта ничего не менял в нем и для id можно юзать uuid

нормальная практика передавать id объекту на вход и получать его скажем из репозитория (например если тебе надо секвенсы юзать). Разумеется если у тебя богомерзские автоинкременты в стиле mysql (где ты можешь знать айдишку только после вставки) только uuid спасут тебя.

ну и да uuid тоже лучше передавать на вход а не в нутри сущности создавать, но... если очень лень)

главное что бы сущность валидной была

нормальная практика передавать id объекту на вход и получать его скажем из репозитория (например если тебе надо секвенсы юзать). Разумеется если у тебя богомерзские автоинкременты в стиле mysql (где ты можешь знать айдишку только после вставки) только uuid спасут тебя.

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

извне - да

если ты не ORM и тебе надо замэпить данные)

Дата маппер не меняет данные, сериализация/десериализация ж не делает переходы состояния

да, ну ты меня понял) я про то что есть разница между доступом и изменением)

Да, и ты меня понял)

Новый объект — это кстати вообще отдельная категория сущностей

Да, если есть возможность типами описывать переходы состояний, то это обычно прям напрашивается. Другое дело, что у нас(в мире жава/пхп/шарп процедурщины) так не принято:(

Да и возможности язык/среда не дают особо

Разве ? Я ж наоборот упоминал штуку из кодгенерированных rpc