@symfony_php

Страница 1417 из 1418
 
Bohdan
27.10.2018
22:35:01
да, именно так

 
фронт отдельно, бек отдельно

 
что там в manifest - я уже и не помню

 
Sergey
27.10.2018
22:35:29
encore? бред имхо
не все херачат фронт на реактах/ангулярах/вуях а обмазываться бандлерами хотят все

Google
 
Den
27.10.2018
22:35:35
та ладно, забейте..

 
Sergey
27.10.2018
22:35:42
что там в manifest - я уже и не помню
по сути его надо юзать для того что бы ресурсы подключать

 
f4rt~
27.10.2018
22:35:44
вот ты часто, по крайней мере раньше, говорил что любишь закрывать разные штуки своим интерфейсом причем не только в случае репозиториев, где может быть много реализаций

 
Sergey
27.10.2018
22:35:55
делает ли это энкор с твигом автоматом - скорее всего... но надо доки читать

 
Den
27.10.2018
22:36:22
думал тут профессионалы..

 
Sergey
27.10.2018
22:36:37
вот ты часто, по крайней мере раньше, говорил что любишь закрывать разные штуки своим интерфейсом причем не только в случае репозиториев, где может быть много реализаций
ну это типа.... смотри: class ProductRepository { private $em; // публичный интерфейс }

 
f4rt~
27.10.2018
22:36:50
ну я понимаю разницу между контракт класса

 
и интерфейс

 
Sergey
27.10.2018
22:37:05
думал тут профессионалы..
тут подготовка к параалимпиаде по программированию, все ок

 
ну я понимаю разницу между контракт класса
и в чем она?

 
"интерфейс" может быть описан сущностью interface но вообще можно и без них о них же и говорить.

 
p.s. у тебя ж еще и абстрактные классы есть) напомню)

 
f4rt~
27.10.2018
22:38:57
и в чем она?
хотел ответить, абзацом, который мне нравится, но потерял его в книге :( а красиво сказать в 2 часа ночи не получается

Google
 
f4rt~
27.10.2018
22:39:25
"интерфейс" может быть описан сущностью interface но вообще можно и без них о них же и говорить.
можно но мы постоянно будем подменять эти понятия в контексте

 
там что то вроде причинноследственной связи интерфейса на контракты

 
но не наоборот

 
Марко так вообще ни одного проекта не написал, где бы не описал, все что можно интерфейсами

 
https://github.com/ShittySoft/php-ce-2018-doctrine-tutorial/blob/feature/aggregate-with-domain-services/src/Authentication/Repository/Users.php

 
Но,справедливости ради, аналогично часто это потому что » интерфейс в одном модуле а реализация в другом

 
https://github.com/ShittySoft/symfony-live-berlin-2018-cqrs-es-workshop/blob/master/src/Domain/Repository/BuildingRepositoryInterface.php && https://github.com/ShittySoft/symfony-live-berlin-2018-cqrs-es-workshop/blob/master/src/Infrastructure/Repository/BuildingRepository.php

 
Sergey
27.10.2018
22:48:22
Но,справедливости ради, аналогично часто это потому что » интерфейс в одном модуле а реализация в другом
и тут надо задаться вопросом для чего тебе это

 
в былые времена часто классы в интерфейсы заворачивались что бы было проще моки делать. В php у тебя нет такой проблемы. Да и большинство в целом тесты не пишут

 
https://github.com/ShittySoft/symfony-live-berlin-2018-cqrs-es-workshop/blob/master/src/Domain/Repository/BuildingRepositoryInterface.php && https://github.com/ShittySoft/symfony-live-berlin-2018-cqrs-es-workshop/blob/master/src/Infrastructure/Repository/BuildingRepository.php
тут вопрос к структуре директорий. Я категорически против такого разделения проекта. Да, это просто. Проще чем тот вариант который предлагаю я. Он не подразумевает анализа зависимостей

 
Bohdan
27.10.2018
22:50:10
тут вопрос к структуре директорий. Я категорически против такого разделения проекта. Да, это просто. Проще чем тот вариант который предлагаю я. Он не подразумевает анализа зависимостей
тот, который в гисте?

 
Sergey
27.10.2018
22:50:23
тот, который в гисте?
тип того, по контекстам.

 
f4rt~
27.10.2018
22:50:39
ну меня больше волнуют репозитории, я,обычно, не ограничиваю себя стандартными get/find/etc и у меня каждый репозиторий умеет делать специфические штуки, которые относятся к отдельному модулю

 
Sergey
27.10.2018
22:50:40
я ж повернут на уменьшении зависимостей

 
f4rt~
27.10.2018
22:50:55
потому что если сейчас у меня доктрина, а завтра файлики, csv/xml/etc я хочу что бы ничего "не поломалось"

 
просто изменилась реализация

 
Sergey
27.10.2018
22:51:53
ну меня больше волнуют репозитории, я,обычно, не ограничиваю себя стандартными get/find/etc и у меня каждый репозиторий умеет делать специфические штуки, которые относятся к отдельному модулю
1. query объекты 2. разделение интерфейса (опять же нужно оооочень хорошо понимать что это тебе дает). Мокать жирный интерфейс так же легко сегодня как и мокать маленький. А вот для декорирования да - маленькие интерфейсы удобнее (опять же в силу ограничений языка - мне нравится как в котлине эту проблему решили через delegates on)

 
Bohdan
27.10.2018
22:52:04
я ж повернут на уменьшении зависимостей
я это частично разделяю, но пока не постиг дзен

 
Sergey
27.10.2018
22:52:08
потому что если сейчас у меня доктрина, а завтра файлики, csv/xml/etc я хочу что бы ничего "не поломалось"
а теперь скажи - как часто ты сторадж меняешь?)

 
и если это для тебя проблема - почему бы не перейти на CQRS?

Google
 
f4rt~
27.10.2018
22:52:18
а теперь скажи - как часто ты сторадж меняешь?)
на текущем проекте довольно часто

 
мои сервисы, должны уметь работать одинаково с любым стораджем

 
и если это для тебя проблема - почему бы не перейти на CQRS?
слишком сложно для меня одного :)

 
Sergey
27.10.2018
22:54:07
слишком сложно для меня одного :)
ммм.... если коротко... у тебя есть операции чисто на запись и чисто на чтение. И каждая из этих операций работает со своим интерфейсом и своими структурами данных в идеале. Ну мол.... у тебя твой "репозиторий" будет возвращать на какой-нибудь findAllBySomething не сущности а DTO

 
CQRS это не рокет сайнс, для этого не надо никаких сложных вещей. Просто разделение операций на "чтение" и "запись"

 
f4rt~
27.10.2018
22:55:14
я не вижу бенефитов которые прям заставили бы изменить много код базы в плане читать AR писать DM круто конечно

 
Sergey
27.10.2018
22:55:19
вот всякие там ивент сурсинги, что бы вот вообще на чтение не зависеть от выбранного способа хранения и структур данных - это уже посложнее существенно

 
Bohdan
27.10.2018
22:55:22
мне кажется, или вот это "возврат dto" это уже за границей cqrs?

 
ну понимаю, зачем и почему так, буквоедством занимаюсь

 
Sergey
27.10.2018
22:55:47
мне кажется, или вот это "возврат dto" это уже за границей cqrs?
почему? у тебя по хорошему одни и те же объекты не должны использоваться на чтение и запись

 
f4rt~
27.10.2018
22:55:52
но у меня при всей своей специфике довольно простые штуки, в плане я сделал штуку, выплюнул сущность, скормил её нашей обертке над фракталом и отдал на фронт

 
Sergey
27.10.2018
22:56:11
но у меня при всей своей специфике довольно простые штуки, в плане я сделал штуку, выплюнул сущность, скормил её нашей обертке над фракталом и отдал на фронт
ну и ок, если тебе удобно)

 
f4rt~
27.10.2018
22:56:35
ну я просто постарался объяснить мотивацию, почему интерфейс понять, норм не норм :)

 
Sergey
27.10.2018
22:56:38
ты ж понимаешь, сильвербулетов нет. Но о вариантах и их сильных/слабых сторонах знать надо. И все должно делаться так что бы это было удобно

 
f4rt~
27.10.2018
22:56:58
да, все сводится к тому что, если понимаешь что делаешь, значит ок :)

 
Bohdan
27.10.2018
22:57:13
почему? у тебя по хорошему одни и те же объекты не должны использоваться на чтение и запись
ладно, тут я потерялся, сейчас лень гуглить дальше формулировки

 
f4rt~
27.10.2018
22:57:27
если видишь явные профиты и у тебя не болит, именно не болит, а не ты привык к боли, пусть будет ?

 
честно спизженная фраза (с)

 
Sergey
27.10.2018
22:57:39
ну я просто постарался объяснить мотивацию, почему интерфейс понять, норм не норм :)
ну надо исходить из профита который ты получаешь. Я вот не получаю особо. Да и декорированием репозиториев не особо занимаюсь. И в целом я чет начал подозрительно коситься в сторону AOP (вот были бы делегаты как в котлине, ух)

 
Bohdan
27.10.2018
22:58:02
возвращаясь к query object - является ли он частью домена? и если да - как держать в домене его "интерфейс"?

Google
 
Sergey
27.10.2018
22:58:18
возвращаясь к query object - является ли он частью домена? и если да - как держать в домене его "интерфейс"?
по идее нет, так как это чисто на чтение штука

 
f4rt~
27.10.2018
22:58:30
а вот пока не убежал @fes0r ответь, про __invoke в интерфейсах :)

 
Sergey
27.10.2018
22:58:38
да и что значит "является ли он частью домена" - у меня вот нет такой проблемы ибо слои не влияютт на структуру проекта

 
f4rt~
27.10.2018
22:58:46
Гайз, есть тут кто кто переодически посматривает/отслеживает всякие штуки,вне доктрины, которые пилит Марко @Ocramius Скажите мне,пожалуйста, почему: Он зовет инвочные классы, аля QueryFunction через $obj->__invoke($args) а не $someKindOfUsers(); Почему, он вносит __invoke в интерфейс, если это не является частью контракта класса с остальными ньюансами, я как то еще могу мириться :)
?

 
Sergey
27.10.2018
22:59:15
а вот пока не убежал @fes0r ответь, про __invoke в интерфейсах :)
что бы не делали люди лишь бы функции не юзать. Не ну тип норм. Только с invoke нюансы есть вида... ($this->myStuff)($args);

 
f4rt~
27.10.2018
22:59:24
я так скорее смотрю это как на невыразительность php

 
Sergey
27.10.2018
22:59:32
ну так и есть в целом

 
__invoke я раньше любил юзать что бы "заставить" разработчиков только один публичный метод у объекта оставлять

 
f4rt~
27.10.2018
22:59:50
что приходится мутаторы описывать что бы получить чуть менее говно, крч обычный трейдофф

 
Bohdan
27.10.2018
22:59:53
окей, тогда зачем "держать в домене" интерфейсы обычных репозиториев? по модулям типа хотя это лечится опять-таки отсутствием разделения на "слои"...

 
Sergey
27.10.2018
23:00:12
явного* разделения на слои.

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

 
и они у тебя так или иначе образуются если ты разделяешь ответственности в коде

 
как по мне оч простое правило - "файлы которые меняются вместе, по одной причине, должны лежать рядом"

 
Bohdan
27.10.2018
23:01:29
да, я помню это правило

 
Sergey
27.10.2018
23:01:45
дальше тебе решать, если у тебя интерфейс штука оч стабильная а реализация меняется часто - возможно имеет смысл разнести по модулям

 
f4rt~
27.10.2018
23:01:46
как по мне оч простое правило - "файлы которые меняются вместе, по одной причине, должны лежать рядом"
а как сюда контекст присобачить?)

 
Sergey
27.10.2018
23:02:08
а как сюда контекст присобачить?)
обычно у разных контекстов причины для изменений разные

 
Bohdan
27.10.2018
23:02:23
но допустим, тот самый lift в схеме типа как у окрамиуса - в домене интерфейс, в инфраструктуре реализация (так как домен ее использует)

 
Sergey
27.10.2018
23:02:33
ну то есть, контексты это штука уже тип посложнее, и чем больше проект тем важнее как по мне.

Google
 
f4rt~
27.10.2018
23:02:46
так я получил свою пищу для ума, всем спасибо :)

 
Bohdan
27.10.2018
23:02:50
но нужен ли интерфейс репозитория в рамках lift, если используется все в контексте одного модуля?

 
Sergey
27.10.2018
23:02:54
но допустим, тот самый lift в схеме типа как у окрамиуса - в домене интерфейс, в инфраструктуре реализация (так как домен ее использует)
да, и окромиус топит за такой вариант потому что любой дурак в такое сумеет

 
и при этом какая-то изоляция да будет)

 
Bohdan
27.10.2018
23:03:22
не спорю, на своём опыте вижу

 
Sergey
27.10.2018
23:03:23
его право, и в целом я никого не буду обвинять если будете юзать такую структуру. Повторюсь - мой вариант плох тем что он чувствителен к декомпозиции.

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

 
Bohdan
27.10.2018
23:04:18
мне тоже нравится больше модульность, так как при 15 папках в папке domain становится грустно

 
но вопрос не в этом)

 
Sergey
27.10.2018
23:04:39
можно делить на контексты и в каждом из контекстов уже хранить domain/infrastructure

 
я так делал - это вполне себе живой вариант

 
Bohdan
27.10.2018
23:05:58
да, логично, хоть и ломает мозг сначала

 
почти бандлы, лол

 
(в хорошем смысле)

 
Dmitriy
28.10.2018
04:09:53
Я вот так разнес проект

 


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

 
Dmitriy
28.10.2018
05:22:45
миграции часть проекта

 
нахера их отключать - загадка

 
Dmitriy
28.10.2018
06:12:39
это миграция со старой БД

 
а не doctrine-migrations

 
Boris
28.10.2018
06:16:06
а что делает requestResolver если не секрет?

Страница 1417 из 1418