Ну и в первом варианте никак. И зачем вообще там подтягивать зависимость? Что бы после выборки проводить манипуляции над объектом Uuid?

После выборки будет просто строка которую я описываю в аннотациях, как @ORM\Column(type="guid")

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

лично я бы ни так, ни эдак не делал

А как бы сделал ты?

Кто как вообще? интересно

Ребята привет, часто встречаю в чужих сорсах такое /** * @var \Ramsey\Uuid\Uuid */ private $id; public function __construct() { $this->id = Uuid::uuid4(); } Выглядит как нарушение инверсии зависимостей и я бы сделал так /** * @var \Ramsey\Uuid\UuidInterface */ private $id; public function __construct(UuidInterface $uuid) { $this->id = $uuid; } Но почему тогда первый вариант конструктора так часто всречается в примерах, в том числе у авторитетных разработчиков(например у ocramius)?

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

только во втором варианте должно быть __construct (ThisEntityId $id, ...) конечно, ну или просто string $id, если не используем VO Id

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

ну и не привязывался бы к докрине, это уже скорее infrastructure layer

// Entity public function __construct(ID $id, /* ...other params */) { $this->id = $id; // ... } // Service public function __construct(IDFactoryInterface $idFactory, /*...other dependencies */) { $this->idFactory = $idFactory; // ... } public function createEntity($params) { // ... return new Entity($this->idFactory->createNew(), $params); } class UuidFactory implements IDFactoryInterface { public function createNew() { return ID::create(Uuid::uuid64()->toString()); } }

я б так поступил

new FooEntity($fooEntityRepository->getNextIdentity()) :)

new FooEntity($fooEntityRepository->getNextIdentity()) :)

а в репозитории откуда брать id?

ну и не привязывался бы к докрине, это уже скорее infrastructure layer

Как? Мапить сущнсти в репозитории?

а это зависит откуда берем id... от new Uuid до $db->nextSequence

как вариант фабрику не в сервис отдавать, а в репозиторий. поясню: вариант с фабрикой показался удобным потому, что заменить можно в контейнере. вроде как отделяемся от конкретных библиотек :)

как вариант фабрику не в сервис отдавать, а в репозиторий. поясню: вариант с фабрикой показался удобным потому, что заменить можно в контейнере. вроде как отделяемся от конкретных библиотек :)

Тогда наверное проще использовать адаптер (UuidGeneratorAdapter) и тоже класть его в контейнер и работать только с его методами.

Спасибо за мнения. Обдумываю.

Как? Мапить сущнсти в репозитории?

в моем понимании dcotrine - это infrastructure. однако, entity я отношу к domain layer, где лишь описаны поля и инварианты. domain ничего не должен знать про infrastructure, поэтому с точки зрения модели я ничего про доктрину не знаю.

как то так

в моем понимании dcotrine - это infrastructure. однако, entity я отношу к domain layer, где лишь описаны поля и инварианты. domain ничего не должен знать про infrastructure, поэтому с точки зрения модели я ничего про доктрину не знаю.

И какое решение в данном случае? Избавиться от аннотаций и мапить через XML?

я бы маппил через yml/xml

Спасибо.

в моем понимании dcotrine - это infrastructure. однако, entity я отношу к domain layer, где лишь описаны поля и инварианты. domain ничего не должен знать про infrastructure, поэтому с точки зрения модели я ничего про доктрину не знаю.

Еще остается привязка к ArrayCollection ведь

Еще остается привязка к ArrayCollection ведь

это если нужен matching. все выборки у меня в QueryService-ах, где я со спокойной душой возвращаю легковесные Dto-шки из слейвов.

репозиторий только для write model

а там можно выехать и на EntityName[]

И какое решение в данном случае? Избавиться от аннотаций и мапить через XML?

аннотации не влияют на сущность

они как бы снаружи, метаданные просто

не влияют

но зачем, если можно в yml (:

в удобном месте

хз, мне так удобнее

хотя сейчас вот в yaml делаю

потому что так сделано в проекте

и в целом мне пофигу

мне главное что бы доктрина была изолирована в пределах репозиториев

верно

ну и как у тебя - неких query сервисах представляющих часть read model

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

о

https://gist.github.com/fesor/d8d06cc20d2861c56148ffd2dfc67220

вот может ты накидаешь идей

это типа хочу read model для очень простых сценариев где лень заморачиваться с сервисами отдельными

и при этом иметь контроль над типами хоть какой

посмотрю позднее чуть чуть

надо уйти с работы (: я никак не могу уйти с работы

надо уйти с работы (: я никак не могу уйти с работы

Та же хуйня

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

надо уйти с работы (: я никак не могу уйти с работы

Дети вам в помощь!

У меня двое

коллега :) тогда не понимаю про работу

Да так получилось, что именно сейчас нужно выложиться. Поэтому столько внимания работе

ну тогда предложение снимается за незнание контекста

затыкание дыр тонущего корабля )

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

Всем доброго времени суток! Есть файл wsdl и sxd можно ли с них сгенерировать СЕРВЕРНЫЙ php код? Клиент сгенерировался из wsdl2php

Всем доброго времени суток! Есть файл wsdl и sxd можно ли с них сгенерировать СЕРВЕРНЫЙ php код? Клиент сгенерировался из wsdl2php

Привет, очень странный вопрос, аналогичный следующему: есть документация API фейсбука, как по ней сгенерировать серверный код фейсбука?

или я не так тебя понял?

бро совсем не так понял =(

поясни тогда))

wsdl описание методов и что они принимают и что отдают

так, да

есть библиотека которая генерирует КЛИЕНТА

ERROR: S client not available

а я ищу то что может сгенерировать классы для SERVICE

это не какой то конкретный сайт типа фб

а сторонний сервис

так фб это тоже сторонний сервис

ты не создаешь свой фб

а тут надо создать свой сервис на основе того wsdl файла

Салам Нурик!

насколько я знаю wsdl2php генерит и то что клиент шлет, и то что сервер отдает

и те и другие классы

Салам Нурик!

Привет

насколько я знаю wsdl2php генерит и то что клиент шлет, и то что сервер отдает

нет только клиента

аа, тогда попробуй вот че

если есть методы генерации серввера дай знать )

https://github.com/wsdl2phpgenerator/wsdl2phpgenerator

он и то и то генерит

я использовал пару раз

правда с некоторыми wsdl он проебывал пару атрибутов, но там скорее дело в сервисах было) в основном все ок

там все просто, травишь ему wsdl и он тебе выплюнет обертку над вызовами, классы запросов и классы ответов

он генерит сервер?

я его и юзаю

он выблевал только клиента

которому скармливаешь URL

=)

хм оч странно

а можешь пример привести абстрактный что бы ты хотел чтоб он тебе сгенерил?

у меня все еще сохраняется чувство что я не врубаюсь о чем ты))

давай сразу скину то говно)

что дали мне

Вот файлики

надо поднять используя эти интерфейсы свой сервис

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