NS
`return $this->hasOne(Post::class);
тут не особо можно понизить связанность разве нет?
Size: a a a
2021 February 18
AN
Например ларавел
тут не особо можно понизить связанность разве нет?
тут не особо можно понизить связанность разве нет?
не особо. Но речь же про контексты насколько я понимаю? Если Post в контексте $this то все же норм?
NS
не особо. Но речь же про контексты насколько я понимаю? Если Post в контексте $this то все же норм?
Речь про то если нам нужно видеть сущности из соседней папки не лучше ли их объявить в родительской
AN
Речь про то если нам нужно видеть сущности из соседней папки не лучше ли их объявить в родительской
эммм.. как то вы не о том мне кажется думаете. Какая разница вам будет, если напишите вы $this->hasOne(Post::class) или напишите вы $this->hasOne(AnotherNamespace/Post::class)
?
?
AN
ну то есть изолированность не строят же только по объектам БД. Ее же строят и на других уровнях тоже.
DT
Как тогда получать мне рейтинг поста?
Ходить в публичный интерфейс модуля рейтинга и просить рейтинг для поста номер такой то
AN
тут как бы что Post::class что AnotherNamesapce/Post::class жесткая связанность. Вы этим ее ни как не уменьшили
AN
Ходить в публичный интерфейс модуля рейтинга и просить рейтинг для поста номер такой то
я так полагаю что речь еще и про консистентность в БД стоит. Ему надо типа ОРМ объект построить со связями. Он об этом парится.
NS
эммм.. как то вы не о том мне кажется думаете. Какая разница вам будет, если напишите вы $this->hasOne(Post::class) или напишите вы $this->hasOne(AnotherNamespace/Post::class)
?
?
Как раз про это. Эти две папки между собой должны максимально мало знать друг о друге и везде это можно решить через интерфейсы но когда мы говорим о связях сущностей тут не подсунуть интерфейсы . Вот я задаюсь вопросом не лучше ли указать эту связь в самой родительской папке тем самым вынести ее из тех двух
DT
Как раз про это. Эти две папки между собой должны максимально мало знать друг о друге и везде это можно решить через интерфейсы но когда мы говорим о связях сущностей тут не подсунуть интерфейсы . Вот я задаюсь вопросом не лучше ли указать эту связь в самой родительской папке тем самым вынести ее из тех двух
А зачем сущностям связь
AN
А зачем сущностям связь
консистентность в БД. Нужно на уровне БД подвтерждать что такая запись реально есть, и связывать ее через внешний ключ
SB
Как тогда получать мне рейтинг поста?
Никак не получайте
https://martinfowler.com/bliki/TellDontAsk.html
https://martinfowler.com/bliki/TellDontAsk.html
NS
Ходить в публичный интерфейс модуля рейтинга и просить рейтинг для поста номер такой то
С типизацией (Post $post) рейтинг просить приятнее чем по обезличнному номеру
DT
С типизацией (Post $post) рейтинг просить приятнее чем по обезличнному номеру
проси по
PostId(15) не обезличенно достаточноAN
Как раз про это. Эти две папки между собой должны максимально мало знать друг о друге и везде это можно решить через интерфейсы но когда мы говорим о связях сущностей тут не подсунуть интерфейсы . Вот я задаюсь вопросом не лучше ли указать эту связь в самой родительской папке тем самым вынести ее из тех двух
ну вы где то не туда свернули. То есть построить слабосвязанные модули ограничивая себя каким то выбором ОРМ движка, как это так? Речь не о том как у вас на уровне ОРМ либы будут сущности мапится, а о том на сколько изолированы модули. Задайтесь вопросом, что будет с вашим приложением, если вы вдруг решите заменить ОРМ либу?
NS
ну вы где то не туда свернули. То есть построить слабосвязанные модули ограничивая себя каким то выбором ОРМ движка, как это так? Речь не о том как у вас на уровне ОРМ либы будут сущности мапится, а о том на сколько изолированы модули. Задайтесь вопросом, что будет с вашим приложением, если вы вдруг решите заменить ОРМ либу?
Не указывать связи в самих сущностях, а получать через какие нибудь репозитории которые можно заинтерфейсить?
VC
Добрый вечер, допустим у нас есть фреймворк с возможностью разделения на модули. Хотелось бы услышать ваше мнение стоит ли объявлять сущности внутри модулей? Или же объявить их все в "основе"?
не можно, а нужно
NS
не можно, а нужно
Прочтите сообщение, там дфиринциальные вопросы, не ясно за что вы ратуете
AN
Не указывать связи в самих сущностях, а получать через какие нибудь репозитории которые можно заинтерфейсить?
ну типа того да. Не работать на прямую с тем что дает ОРМ. ОРМ это какой то один слой из всего. У вас все ровно должны быть какие то доменные объекты. Та же статься и рейтинги. А вот где они будут хранится и как, это уже второй вопрос. И тут уже если вам нужна консистентность на уровне БД то у вас не будет других выборов как делать типа ->hasOne в вашей орм.