клонирование - не самая дешёвая операция, но в контексте пхп на это можно хер просто положить)

а если объект большой? Копировать накладно

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

ну короч там начинаются веселые пляски

p.s. все намного проще когда у тебя синхронно однопоточно и никогда нет конкуретных запросов)

кто нибудь подключал asterisk ?это сложно?

кто нибудь подключал asterisk ?это сложно?

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

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

я продолжу другим интересным вопросом :D

@fes0r теперь я включусь: допустим, я хочу обязать все репозитории иметь два метода: save и delete (persist и remove, не суть важно) первая идея - два интерфейса под каждый метод но! в сигнатуре методов будет в лучшем случае object, а то и вообще никакого тайпхинта нарушение lsp наяву - require no more, promise no less не работает с одной стороны - дерьмо получается, с другой стороны - я не собираюсь использовать эти интерфейсы для автовайринга или подобного - просто контракт для репозиториев

че делать-то?

сейчас за delete в репозитории звездюлей получишь)

сейчас за delete в репозитории звездюлей получишь)

нононо, сейчас обсудим

delete вполне себе типизабельная штука, принимает конкретную сущность ведь флаш вот вынесу по примеру в отдельный сервис - лучше втянуть два сервиса, чем в каждой репе дублировать flush

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

delete вполне себе типизабельная штука, принимает конкретную сущность ведь флаш вот вынесу по примеру в отдельный сервис - лучше втянуть два сервиса, чем в каждой репе дублировать flush

тут вечный холивар на тему, может ли репозиторий в принципе иметь такой метод)

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

контракт - я хочу знать, что мои репозитории умеют сохранять и удалять своих подопечных

тут вечный холивар на тему, может ли репозиторий в принципе иметь такой метод)

ну в принципе сюда можно подтянуть srp как аргумент против моего варианта... но хзхз пока что

@fes0r теперь я включусь: допустим, я хочу обязать все репозитории иметь два метода: save и delete (persist и remove, не суть важно) первая идея - два интерфейса под каждый метод но! в сигнатуре методов будет в лучшем случае object, а то и вообще никакого тайпхинта нарушение lsp наяву - require no more, promise no less не работает с одной стороны - дерьмо получается, с другой стороны - я не собираюсь использовать эти интерфейсы для автовайринга или подобного - просто контракт для репозиториев

не ну на самом деле delete в репозитории так себе, но это отдельная история (ничего не удалять)

выносить сохранение отдельно, удаление отдельно по полному srp - как-то эребор

не ну на самом деле delete в репозитории так себе, но это отдельная история (ничего не удалять)

soft delete имеешь ввиду?

лично в моей картине мира у репозитория такого метода нет

а save у него есть?

а удаляешь ты через em?

через active=false)

сейва тоже нет) он умеет у меня ток искать)

а персистишь новые сущности как?

репозиторий разный на каждый случай, далеко не каждый репозиторий должен иметь тот же save о каком общем контракте может идти речь

а персистишь новые сущности как?

через em эт его головная боль

я просто не хочу таскать его везде и не хочу развивать тему Сергея и делать Saver и Remover какие-нибудь

но в общем если смотреть глобальнее, то ответ - никак, пока не будет дженериков

хотя тоже стоит об этом подумать

но в общем если смотреть глобальнее, то ответ - никак, пока не будет дженериков

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

ну хз. em - вполне се сервис. можешь его в свой инкапсулировать, запрятав раз и навсегда

но для меня общий контракт для репозиториев звучит какой-то дичью... типа, подменить UserRepository на ProductRepository?

и, да, я с Дмитрием полностью согласен. Вне зависимости от конечной реализации, репозиторий - штука нихера не обязательно типизированная. Это нечто, что умеет "чёт делать" с конкретной сущностью для которой написано, имхо

но для меня общий контракт для репозиториев звучит какой-то дичью... типа, подменить UserRepository на ProductRepository?

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

и, да, я с Дмитрием полностью согласен. Вне зависимости от конечной реализации, репозиторий - штука нихера не обязательно типизированная. Это нечто, что умеет "чёт делать" с конкретной сущностью для которой написано, имхо

разве сущность - не тип?

ну хз. em - вполне се сервис. можешь его в свой инкапсулировать, запрятав раз и навсегда

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

разве сущность - не тип?

я, наверное, херово выразился. у тебя есть репозиторий, но схера ли он будет для всех один?

точнее, с 1м интерфейсом

он не будет для всех один

и интерфейс у него не будет один

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

это вопрос не контрактов, а соглашений по коду и делается каким-нить пост-процессором при комитах или кодревью

ну у тебя есть надцать репозиториев, каждый из которых имлиментит save и delete интерфейсы

это вопрос не контрактов, а соглашений по коду и делается каким-нить пост-процессором при комитах или кодревью

да, неправильно выразился, это скорее convention, нежели контракт

ну вот делать интерфейс для этого как-то странно... тем более никто не запретит этот интерфейс не реализовывать

ладно, спасибо, господа, подумаю еще над этим еще все же интересна аргументация о том, почему save/delete/flush (возможно) не место в репе если есть ссылочка или запрос в гугл - кидайте, почитаю

да тут раз в неделю стабильно срачи на тему сути репозитория) обычно всё сводится к тому, что он только ищет. Хотя отдельно взятые умные дядьки говорят, что это не всегда так)

да тут все повернуты на ES и разделении read и write сущностей, какие тут вообще репозитории классические... не до них ;)

ну, да. разделение, все дела

даже не на read и write, а на command и query, скорее.

ну, срачи я пропускаю, похоже cqs - не вижу конфликта с тем, чтобы держать save и delete в репе, кроме теоретического srp (уже не говорю про интерфейсы)

ну, с точки зрения буквоедства у тебя за запись и за запрос отвечают 2 разных интерфейса - подходит. но с точки зрения srp, уже чёт не то получается.

у тебя репозиторий внезапно становится вундервафлей, которая прям всё умеет

Такие штуки разруливаются через метаданные сущности, если у тебя есть ограничения накладываемые бд.

это Class Metadata у Фаулера?

у тебя репозиторий внезапно становится вундервафлей, которая прям всё умеет

окей, тогда давай консы сервисов Saver и Remover)

это Class Metadata у Фаулера?

Это вообще любые метаданные для orm, в данном случае аннотации. Но, как заметил @fes0r, всё же не стоит на это полагаться.

ERROR: S client not available

окей, тогда давай консы сервисов Saver и Remover)

консы?

моя нипанимать часть модных слов)

консы?

недостатки типа pro's and con"s

в общем я вроде понял, что возмущение сеттерами в данном случае вызвано плохой семантикой и протеканием инфраструктурных проверок в код предметной области =\

недостатки типа pro's and con"s

хз) я так не упарывался. У Фессора так бизнесс логика трактует. У него чуток ректальная схемка, смешанная

На сколько я понял, у него там es и традиционный подход. Вот и флашит отдельным сервисом. Эт лучше у него уточнять

Это вообще любые метаданные для orm, в данном случае аннотации. Но, как заметил @fes0r, всё же не стоит на это полагаться.

В каком смысле "полагаться не стоит"? Ещё где-то тогда проверять чтоли? о_О

ладно, спасибо, господа, подумаю еще над этим еще все же интересна аргументация о том, почему save/delete/flush (возможно) не место в репе если есть ссылочка или запрос в гугл - кидайте, почитаю

ну, тут действительно крайне спорно. кому-то проще em юзать вообще. у нас save\delete в репе, потому что не хочется таскать везде em, он слишком много умеет. а delete потому что иногда всё таки удаляем, ну и он не во всех репах есть, только там где это надо. flush отдельным сервисом, который умеет только flush, потому что зачастую это надо делать отдельно и именно в значении "синкнуть с базой всё что мы тут наобновляли", т.е. я не могу придумать зачем это пихать в конкретный репозиторий (и если пихать, то в какой. в каждый?) а насчёт интерфейсов, поддержу мнение о том, что это скорее код конвеншен. который всё равно нужен, потому что заставлять юзать интерфейс всё равно придется.

в общем я вроде понял, что возмущение сеттерами в данном случае вызвано плохой семантикой и протеканием инфраструктурных проверок в код предметной области =\

Эм... Немного не понял о чем ты. Сеттеры - плохо, потому, что дают прямой доступ на запись в стейт сущности.

хз) я так не упарывался. У Фессора так бизнесс логика трактует. У него чуток ректальная схемка, смешанная

да, все так. Грязь и слезы. Вперемешку. Есть пара мест где криво границы агрегатов и там пруфовская сущность внутри доктриновской

В каком смысле "полагаться не стоит"? Ещё где-то тогда проверять чтоли? о_О

В том смысле, что доктрина тебя не спасет, если имя будет больше 10 символов а в качестве бд будет мускуль с отключеным стрикт модом.

Эм... Немного не понял о чем ты. Сеттеры - плохо, потому, что дают прямой доступ на запись в стейт сущности.

а в свою очередь прямой доступ на запись в стейт сущности плох тем, что в БЛ нет никакой записи в стейт сущности? Или ещё какие-то причины?

а в свою очередь прямой доступ на запись в стейт сущности плох тем, что в БЛ нет никакой записи в стейт сущности? Или ещё какие-то причины?

Тем, что нарушается инкапсуляция. Кто-то или что-то извне может изменить стейт твоей сущности и результаты в таком случае могут быть непредсказуемые. Ну и вынос логики поведения из сущностей в сервисы считается антипаттерном у нормальных пацанов. https://martinfowler.com/bliki/AnemicDomainModel.html

тогда нарушает ли метод rename инкапсуляцию? public functon rename ($newName) { $this->name = $newName; }

тогда нарушает ли метод rename инкапсуляцию? public functon rename ($newName) { $this->name = $newName; }

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

Да, вечер добрый. Мини рекламку внутри коллектива этому чатику сделали.

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

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

Предмет так и назывался - 1С???

информационные системы логистики

Не любите логистику?

логистика и 1с:предприятие понятия мало чем похожие на мой взгляд (хотя откуда мне знать). ну не вывел в СКД данные из регистра расчета, пусть и связал все справочники с документами, планами видов характеристик и планами видов расчета, с кем не бывает)

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

поресерчил чуть про репозитории и save/delete в них к примеру: http://richarddingwall.name/2009/10/22/repositories-dont-have-save-methods/ если воспринимать репозиторий, как коллекцию - add/remove выглядят вполне логичными

Те ж сказали в чем смысл вчера)

все равно пытаюсь докопаться до глубин правды)

есть такая ошибка, варинтов решения несколько. можно просто прописать в htaccess php_value memory_limit '64M' ? PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 262144 bytes) in /var/www/%sitename etc%

есть такая ошибка, варинтов решения несколько. можно просто прописать в htaccess php_value memory_limit '64M' ? PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 262144 bytes) in /var/www/%sitename etc%

Попробуй