И
пролистай
Size: a a a
2020 May 13
DE
В ларе у модели по дефолту есть поведение
Это инфраструктурные методы, а не пользовательское поведение.
RK
> Как бы объяснить.
Модель сама по себе минималистична. Она знает откуда взять данные, в каком виде отдать их, и в каком засунуть обратно в базу.
Вы зациклены на Eloquent. И словом "модель" снова и снова называете голую структуру данных без поведения со строкой из БД, которую передаёте своим сервисам-процедурам.
> Вынесение БИЗНЕС-ЛОГИКИ из МОДЕЛИ не нарушает ООП!
Объект состоит из состояния и поведения, инкапсулированного внутри.
Если есть только данные и нет поведения, то это не объект, а структура данных.
Если есть только поведение и нет состояния, то это функция или процедура как любой ваш сервис.
В полноценном объекте состояние (поля) спрятаны и работа с ними производится через методы. Это называется инкапсуляцией.
Вынос бизнес логики (поведения) из ЛЮБОГО ОБЪЕКТА с открытием полей наружу нарушает инкапсуляцию и это уже объектом не является.
Модель сама по себе минималистична. Она знает откуда взять данные, в каком виде отдать их, и в каком засунуть обратно в базу.
Вы зациклены на Eloquent. И словом "модель" снова и снова называете голую структуру данных без поведения со строкой из БД, которую передаёте своим сервисам-процедурам.
> Вынесение БИЗНЕС-ЛОГИКИ из МОДЕЛИ не нарушает ООП!
Объект состоит из состояния и поведения, инкапсулированного внутри.
Если есть только данные и нет поведения, то это не объект, а структура данных.
Если есть только поведение и нет состояния, то это функция или процедура как любой ваш сервис.
В полноценном объекте состояние (поля) спрятаны и работа с ними производится через методы. Это называется инкапсуляцией.
Вынос бизнес логики (поведения) из ЛЮБОГО ОБЪЕКТА с открытием полей наружу нарушает инкапсуляцию и это уже объектом не является.
А по-моему модель без элока это репозиторий😅
RK
Который представляет из себя интерфейс взаимодействия со структурой данных без драйвера взаимодействия с чем либо
RK
Берём репозиторий цепляем элок, получаем модель
RK
Элок выступает в качестве драйвера общения с субд
DE
В общем сущности и агрегаты с бизнес-логикой хоть на чём это так. Хоть на Doctrine, хоть при желании на AR.
ИЛ
DE
ИЛ
28 методов
И
а что смущает?
ИЛ
а что смущает?
Цифра в 28 методов
RK
И кстати entity это представление сущности в диаграмме, реализация может иначе вообще называться
И
Цифра в 28 методов
а в ларе классы только по 5 методов что ли
A
Цифра в 28 методов
слева там write-методы. справа read.
ИЛ
а в ларе классы только по 5 методов что ли
Вот кстати пример
DE
28 методов
С бизнес-логикой только левые. Правые геттеры вообще не нужны.
ИЛ
Вот кстати пример
Там есть логика работы с тэгами. Можно вынести в отдельный класс, задача которого взаимодействовать с моделью Advert в контексте тэгов
AH
> Как бы объяснить.
Модель сама по себе минималистична. Она знает откуда взять данные, в каком виде отдать их, и в каком засунуть обратно в базу.
Вы зациклены на Eloquent. И словом "модель" снова и снова называете голую структуру данных без поведения со строкой из БД, которую передаёте своим сервисам-процедурам.
> Вынесение БИЗНЕС-ЛОГИКИ из МОДЕЛИ не нарушает ООП!
Объект состоит из состояния и поведения, инкапсулированного внутри.
Если есть только данные и нет поведения, то это не объект, а структура данных.
Если есть только поведение и нет состояния, то это функция или процедура как любой ваш сервис.
В полноценном объекте состояние (поля) спрятаны и работа с ними производится через методы. Это называется инкапсуляцией.
Вынос бизнес логики (поведения) из ЛЮБОГО ОБЪЕКТА с открытием полей наружу нарушает инкапсуляцию и это уже объектом не является.
Модель сама по себе минималистична. Она знает откуда взять данные, в каком виде отдать их, и в каком засунуть обратно в базу.
Вы зациклены на Eloquent. И словом "модель" снова и снова называете голую структуру данных без поведения со строкой из БД, которую передаёте своим сервисам-процедурам.
> Вынесение БИЗНЕС-ЛОГИКИ из МОДЕЛИ не нарушает ООП!
Объект состоит из состояния и поведения, инкапсулированного внутри.
Если есть только данные и нет поведения, то это не объект, а структура данных.
Если есть только поведение и нет состояния, то это функция или процедура как любой ваш сервис.
В полноценном объекте состояние (поля) спрятаны и работа с ними производится через методы. Это называется инкапсуляцией.
Вынос бизнес логики (поведения) из ЛЮБОГО ОБЪЕКТА с открытием полей наружу нарушает инкапсуляцию и это уже объектом не является.
Модель Laravel предоставляет все необходимые методы для работы с базой данных. Каждая модель отвечает за свой участок кода. Смешивать их - плохо. В Вашем коде, например, есть открепление записи фаворита, то есть действие над одной моделью из другой. Во-первых, это бизнес-логика, что-то к кому-то цеплять. Во-вторых, это неочевидное поведение, т.к. общение происходит в нелогичном для этого месте.
Если Вы так кичитесь своими знаниями ООП, дак выкиньте этот Laravel - это ж чемодан антипаттернов. На кой от Вам вообще нужен? Пишите свой код. Будет всё по канону... Вашему.
Начинаешь надоедать со своей инкапсуляцией. Мне по-барабану что и как называется. Я вижу принцип толстой модели, объединяющей в себе как работу с данными, так и бизнес-логику, включая работу с не родными данными из других моделей. Это плохо.
Если следовать Вашим принципам, то на фига вообще нужны контроллеры, сервисы, валидаторы?... Суйте всё в модели! Это ж инкапсуляция! Не отказывайтесь от своих принципов.
Если Вы так кичитесь своими знаниями ООП, дак выкиньте этот Laravel - это ж чемодан антипаттернов. На кой от Вам вообще нужен? Пишите свой код. Будет всё по канону... Вашему.
Начинаешь надоедать со своей инкапсуляцией. Мне по-барабану что и как называется. Я вижу принцип толстой модели, объединяющей в себе как работу с данными, так и бизнес-логику, включая работу с не родными данными из других моделей. Это плохо.
Если следовать Вашим принципам, то на фига вообще нужны контроллеры, сервисы, валидаторы?... Суйте всё в модели! Это ж инкапсуляция! Не отказывайтесь от своих принципов.