AP
Тут важен подход к обработке даных
Size: a a a
2020 June 19
АЯ
отличие от метода объекта процедура самодостаточна
АЯ
другими словами - когда ты в класс запихиваешь статический метод, ты по факту создаёшь процедуру, которая работает вообще вне контекста объекта
АЯ
от ООП в ней только то. что она привязана к классу (заметьте, в аббревиатуре ООП вообще нет ни слова про классы).
вынеси её отдельно и ровным счётом ничего не изменится
вынеси её отдельно и ровным счётом ничего не изменится
ВС
Хорошо. Как data mapper решает эту проблему?
ВС
Никакой разницы нет в случае с AR, кроме разделения ответственности.
АЯ
хм, ну помимо разделения ответсвенности (что немаловажно) репозитории как бы не статичные а являются объектами с конкретным назначением и функционалом
ВС
хм, ну помимо разделения ответсвенности (что немаловажно) репозитории как бы не статичные а являются объектами с конкретным назначением и функционалом
Но мы всё ещё можем положить в модель всё, что угодно, не так ли?
AP
Никакой разницы нет в случае с AR, кроме разделения ответственности.
Типо да. Дата мапер просто гибкий.
ВС
Типо да. Дата мапер просто гибкий.
Угу
АЯ
Но мы всё ещё можем положить в модель всё, что угодно, не так ли?
"можем" и "стоит" не одно и то же.
ВС
"можем" и "стоит" не одно и то же.
Я просто Вас подталкиваю к выводу, что всё очень зависит от реализации
АЯ
заложить функционал мы можем в любую модель, главное чтоб это функционал относился к этой моделе
АЯ
Я просто Вас подталкиваю к выводу, что всё очень зависит от реализации
понятное дело, что всё зависит от реализации. только в случае с репозиториями у вас есть возможность разделить ответсвенность, а в случае АР нет.
АЯ
то есть это заведомый костыль
AP
Но мы всё ещё можем положить в модель всё, что угодно, не так ли?
То есть? Можно же мапить dto и передавать в модель. И так же само можно на dto повесить функционал АР. Просто это нужно если мы вообще хотим отделить нашу модель от уровня хранения даных, что я считаю правильным
ВС
понятное дело, что всё зависит от реализации. только в случае с репозиториями у вас есть возможность разделить ответсвенность, а в случае АР нет.
Что да, то да. Но для небольших проектов это разделение будет избыточно: сложность выше, а профита нет особо
AP
понятное дело, что всё зависит от реализации. только в случае с репозиториями у вас есть возможность разделить ответсвенность, а в случае АР нет.
Так я делаю репозитории с использованием АР
ВС
То есть? Можно же мапить dto и передавать в модель. И так же само можно на dto повесить функционал АР. Просто это нужно если мы вообще хотим отделить нашу модель от уровня хранения даных, что я считаю правильным
Я имел ввиду то, о чём говорил выше Андрей: статика, процедуры и т.д.
AP
Одно другому не мешает