я частенько так делаю)

но если у тебя большая система тебе ооочень легко потом заблудится где какая структура юзается

и рефакторить становится сложнова-то

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

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

Тем что они не модели?)

т.е. твоим отношением к ним

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

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

т.е. твоим отношением к ним

Скорее их положением в системе

class UserDTO { public $id; public $name; public $birthday; }

вот пример DTO

если ты заметил - все проперти публичны

потому что это тупо структура данных

это не "объект" в привычном стиле

а где контроль над типами?

просто составной тип данных

а где контроль над типами?

phpdoc?) пока нет тайп хинтинга для пропертей только так)

ну ок

логично вроде

а где контроль над типами?

тебя интересует не контроль над типами в рантайме, а статическая информация, то как это в коде

Для тех кто в танке - что есть "анемичные модели" (объекты без поведения, что ли?) и что есть "контроль над типами"?

потому что только статическая информация сильно помогает тебе при рефакторингах

Для тех кто в танке - что есть "анемичные модели" (объекты без поведения, что ли?) и что есть "контроль над типами"?

да

Для тех кто в танке - что есть "анемичные модели" (объекты без поведения, что ли?) и что есть "контроль над типами"?

да, объект без "гемоглабина" - логики

Для тех кто в танке - что есть "анемичные модели" (объекты без поведения, что ли?) и что есть "контроль над типами"?

контроль над типами.... ну... вот тебе пример.

function toDTO(): array;

контроль над типами это для языков со слабой типизацией

оно возвращает тупо массив... непонятно что внутри

или как оно проавильно называется

а если бы было toDTO(): UserDTO

то все уже намного лучше, и ты легко можешь в любимой IDE найти все места где юзается это DTO

контроль над типами это для языков со слабой типизацией

это просто возможность описать типы данных статически, в коде... что бы не надо было запускать (или интерпритировать в голове) что бы узнать "что же там"

сильно экономит время на чтение кода

@f3ath @fes0r спасибо, стало яснее.

а читаем код мы намного чаще чем пишем, а потому это то время которое надо экономить

ты потратишь на это DTO лишних 5 минут и возможно потом сэкономишь пол часа

такой вопрос тогда. есть слой A и слой B в приложении, которые обмениваются ДТОшками. A и B два разных модуля, к какому из них отнести ДТО?

такой вопрос тогда. есть слой A и слой B в приложении, которые обмениваются ДТОшками. A и B два разных модуля, к какому из них отнести ДТО?

что значит "обмениваются"?

ну один их производит, другой потребляет

самый такой.... "правильный" что-ли пример это архитектура портов и адаптеров

или гексагональная архитектура

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

если коротко - какой слой от какого ты хочешь изолировать при помощи DTO?

ну так... намекну что слой с UI не может не зависить от слоя с логикой... либо между этими слоями есть еще кто-то

у меня есть GitGatewayInterface, который из гита получает DTO с описанием разных сущностей (коммит, тег, итд). Есть Модели этих же сущностей, с логикой, которые используются в приложении. A - имплементация этого интерфейса, B - приложенме, которое зависит от интерфейса (получает его инстанс как зависимость). Они два разных модуля. К какому из них отнести ДТО?

ни к какому наверно?

к интерфейсу?

)))

давай по другому

поскольку они оба то интерфейса зависят

кто хочет получить DTO?

приложение

если коротко - что делает приложение напомни

приложение

ну то есть у тебя есть некий application layer

печатает ChangeLog

вот там и должен быть dto

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

к интерфейсу?

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

окей

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

неверно

Проясни

кто у тебя главный - интерфейс или приложение?

я вижу зависимости так [Приложение] -> [Интерфейс+ДТО] <- [Гит]

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

я вижу зависимости так [Приложение] -> [Интерфейс+ДТО] <- [Гит]

почему?

он и не является

зачем тогда тебе приложение в твоей схеме? что оно делает если у тебя интерфейс напрямую получает нужную информацию?

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

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

приложение не зависит от интерфейса

как не зависит?

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

ну блин в этом смысл разделение

интерфейс зависит от приложения, а не приложение зависит от интерфейса

приложение ничего вообще не знает об интерфейсе

как не зависит?

зачем?

зачем в конструктор?

идем в википедию читать на тему Inversion of control

не понимаю если у тебя есть class A { __construct(B $b); }

кто от кого зависит*

?

A от B, правлиьно?

повторюсь

то что ты передаешь UI в конструктор приложения - это уже ошибка

приложение надо передавать в конструктор UI

образно

Inversion of Control это называется

у меня нет UI в этой схеме

не приложение дергает фреймворк, а фреймворк дергает приложение

UI за скобками пока

я не понимаю

интерфейс зависит от приложения, а не приложение зависит от интерфейса

В этом месте мне хочется тоже сказать "неверно".

В этом месте мне хочется тоже сказать "неверно".

аргументируй

и почитай про inversion of control

A { __construct(B $b); } B - интерфейс

A - приложене

A зависит от B

и почитай про inversion of control

Это не особо объясняет.

что тут н етак?

что тут н етак?

то что у тебя приложение зависит от UI)

а приложение НИЧЕГО не должно знать о UI