RK
Size: a a a
2020 May 13
AH
Не по адресу, братан)
С
В этом есть грань разницы между MVC и фреймворками.
Лара не поддается описанию конкретного шаблона - она использует многие из них, включая не очень хорошие, да.
Но писать код всегда нужно так, будто после вас его поддерживать будет неуравновешенный и склонный к насилию психопат, который знает где вы живёте.
Лара не поддается описанию конкретного шаблона - она использует многие из них, включая не очень хорошие, да.
Но писать код всегда нужно так, будто после вас его поддерживать будет неуравновешенный и склонный к насилию психопат, который знает где вы живёте.
Слышал эту поговорку уже))) Лара, да, юзает много паттернов и антипаттернов)
VB
писать в коментариях адрес и паспортные даные, так и запишем
AH
Сергей
Слышал эту поговорку уже))) Лара, да, юзает много паттернов и антипаттернов)
Вот-вот!
И применять тот или иной метод разработки - задача разработчика.
Одно дело, если бы та модель была вне Лары, например, самопал - там бы вопросов было значительно меньше, и то можно было бы половину методов вынести в сервисы, а если бы была структура именно MVC, то вопросов бы не было вовсе. НО там Лара, а для разработки кода на Ларе это, как уже писал выше, яркий пример как делать не надо.
И применять тот или иной метод разработки - задача разработчика.
Одно дело, если бы та модель была вне Лары, например, самопал - там бы вопросов было значительно меньше, и то можно было бы половину методов вынести в сервисы, а если бы была структура именно MVC, то вопросов бы не было вовсе. НО там Лара, а для разработки кода на Ларе это, как уже писал выше, яркий пример как делать не надо.
AH
Самое смешное в том, что сервисы-то в том проекте есть: https://github.com/ElisDN/laravel-demo-board/tree/master/app/Services
И
Самое смешное в том, что сервисы-то в том проекте есть: https://github.com/ElisDN/laravel-demo-board/tree/master/app/Services
Дмитрия критикой не испугаешь! )
AH
Дмитрия критикой не испугаешь! )
Цель не напугать, а донести абсурдность ситуации)
И
Цель не напугать, а донести абсурдность ситуации)
Андрей, а я вот не помню. Ты за что больше топишь - за сервисы или классы-команды?
И
В двух словах
AH
Андрей, а я вот не помню. Ты за что больше топишь - за сервисы или классы-команды?
Что за классы-команды?
Вообще я за то, чтобы каждый участок кода делал то, для чего он предназначен.
В частности, задача контроллеров - контроллировать, валидаторов - валидировать, моделей - содержать инфу об инстансе записи БД, а сервисов - отвечать за бизнес-логику. Это если упрощённо.
Вообще я за то, чтобы каждый участок кода делал то, для чего он предназначен.
В частности, задача контроллеров - контроллировать, валидаторов - валидировать, моделей - содержать инфу об инстансе записи БД, а сервисов - отвечать за бизнес-логику. Это если упрощённо.
И
Что за классы-команды?
Вообще я за то, чтобы каждый участок кода делал то, для чего он предназначен.
В частности, задача контроллеров - контроллировать, валидаторов - валидировать, моделей - содержать инфу об инстансе записи БД, а сервисов - отвечать за бизнес-логику. Это если упрощённо.
Вообще я за то, чтобы каждый участок кода делал то, для чего он предназначен.
В частности, задача контроллеров - контроллировать, валидаторов - валидировать, моделей - содержать инфу об инстансе записи БД, а сервисов - отвечать за бизнес-логику. Это если упрощённо.
Сейчас покажу что это
IG
Как бы объяснить.
Модель сама по себе минималистична. Она знает откуда взять данные, в каком виде отдать их, и в каком засунуть обратно в базу. Также каким образом связаться с другими моделями (это уже мутация на уровне билдера). По сути, всё.
Если же совать в модель бизнес-логику, это получится жирная модель, которая, по сути, кроме своего предназначения будет еще и играть роль сервиса.
Далее, ООП придумали чтобы избавиться от дубляжа кода, а также для упрощения. Вот, например, где-то нужно получить какой-то метод - по идее, нужно обратиться к сервису, выполняющему нужную логику, но никак не к модели User, производящей отключение модели Favorite через связующую pivot-таблицу. Это, как минимум, нелогично и вводит в заблуждение, т.к. модель User, по сути, всё что должна знать о фаворитах, так это как с ними связаться через релейшен, не более.
В данном же случае то же самое ООП применяют для усложнения логики, приговаривая "ну это же ООП, ты чоооо, это же не процедурное программирование". Блин, процедурное программирование - это совсем другое. В корне! Вынесение БИЗНЕС-ЛОГИКИ из МОДЕЛИ не нарушает ООП! Оно ИСПРАВЛЯЕТ логику приложения и упрощает работу с ним как для создателя, так и для тех кто этот код будет читать.
Модель сама по себе минималистична. Она знает откуда взять данные, в каком виде отдать их, и в каком засунуть обратно в базу. Также каким образом связаться с другими моделями (это уже мутация на уровне билдера). По сути, всё.
Если же совать в модель бизнес-логику, это получится жирная модель, которая, по сути, кроме своего предназначения будет еще и играть роль сервиса.
Далее, ООП придумали чтобы избавиться от дубляжа кода, а также для упрощения. Вот, например, где-то нужно получить какой-то метод - по идее, нужно обратиться к сервису, выполняющему нужную логику, но никак не к модели User, производящей отключение модели Favorite через связующую pivot-таблицу. Это, как минимум, нелогично и вводит в заблуждение, т.к. модель User, по сути, всё что должна знать о фаворитах, так это как с ними связаться через релейшен, не более.
В данном же случае то же самое ООП применяют для усложнения логики, приговаривая "ну это же ООП, ты чоооо, это же не процедурное программирование". Блин, процедурное программирование - это совсем другое. В корне! Вынесение БИЗНЕС-ЛОГИКИ из МОДЕЛИ не нарушает ООП! Оно ИСПРАВЛЯЕТ логику приложения и упрощает работу с ним как для создателя, так и для тех кто этот код будет читать.
ну да каждый класс выполняет свое
DE
Как бы объяснить.
Модель сама по себе минималистична. Она знает откуда взять данные, в каком виде отдать их, и в каком засунуть обратно в базу. Также каким образом связаться с другими моделями (это уже мутация на уровне билдера). По сути, всё.
Если же совать в модель бизнес-логику, это получится жирная модель, которая, по сути, кроме своего предназначения будет еще и играть роль сервиса.
Далее, ООП придумали чтобы избавиться от дубляжа кода, а также для упрощения. Вот, например, где-то нужно получить какой-то метод - по идее, нужно обратиться к сервису, выполняющему нужную логику, но никак не к модели User, производящей отключение модели Favorite через связующую pivot-таблицу. Это, как минимум, нелогично и вводит в заблуждение, т.к. модель User, по сути, всё что должна знать о фаворитах, так это как с ними связаться через релейшен, не более.
В данном же случае то же самое ООП применяют для усложнения логики, приговаривая "ну это же ООП, ты чоооо, это же не процедурное программирование". Блин, процедурное программирование - это совсем другое. В корне! Вынесение БИЗНЕС-ЛОГИКИ из МОДЕЛИ не нарушает ООП! Оно ИСПРАВЛЯЕТ логику приложения и упрощает работу с ним как для создателя, так и для тех кто этот код будет читать.
Модель сама по себе минималистична. Она знает откуда взять данные, в каком виде отдать их, и в каком засунуть обратно в базу. Также каким образом связаться с другими моделями (это уже мутация на уровне билдера). По сути, всё.
Если же совать в модель бизнес-логику, это получится жирная модель, которая, по сути, кроме своего предназначения будет еще и играть роль сервиса.
Далее, ООП придумали чтобы избавиться от дубляжа кода, а также для упрощения. Вот, например, где-то нужно получить какой-то метод - по идее, нужно обратиться к сервису, выполняющему нужную логику, но никак не к модели User, производящей отключение модели Favorite через связующую pivot-таблицу. Это, как минимум, нелогично и вводит в заблуждение, т.к. модель User, по сути, всё что должна знать о фаворитах, так это как с ними связаться через релейшен, не более.
В данном же случае то же самое ООП применяют для усложнения логики, приговаривая "ну это же ООП, ты чоооо, это же не процедурное программирование". Блин, процедурное программирование - это совсем другое. В корне! Вынесение БИЗНЕС-ЛОГИКИ из МОДЕЛИ не нарушает ООП! Оно ИСПРАВЛЯЕТ логику приложения и упрощает работу с ним как для создателя, так и для тех кто этот код будет читать.
> Как бы объяснить.
Модель сама по себе минималистична. Она знает откуда взять данные, в каком виде отдать их, и в каком засунуть обратно в базу.
Вы зациклены на Eloquent. И словом "модель" снова и снова называете голую структуру данных без поведения со строкой из БД, которую передаёте своим сервисам-процедурам.
> Вынесение БИЗНЕС-ЛОГИКИ из МОДЕЛИ не нарушает ООП!
Объект состоит из состояния и поведения, инкапсулированного внутри.
Если есть только данные и нет поведения, то это не объект, а структура данных.
Если есть только поведение и нет состояния, то это функция или процедура как любой ваш сервис.
В полноценном объекте состояние (поля) спрятаны и работа с ними производится через методы. Это называется инкапсуляцией.
Вынос бизнес логики (поведения) из ЛЮБОГО ОБЪЕКТА с открытием полей наружу нарушает инкапсуляцию и это уже объектом не является.
Модель сама по себе минималистична. Она знает откуда взять данные, в каком виде отдать их, и в каком засунуть обратно в базу.
Вы зациклены на Eloquent. И словом "модель" снова и снова называете голую структуру данных без поведения со строкой из БД, которую передаёте своим сервисам-процедурам.
> Вынесение БИЗНЕС-ЛОГИКИ из МОДЕЛИ не нарушает ООП!
Объект состоит из состояния и поведения, инкапсулированного внутри.
Если есть только данные и нет поведения, то это не объект, а структура данных.
Если есть только поведение и нет состояния, то это функция или процедура как любой ваш сервис.
В полноценном объекте состояние (поля) спрятаны и работа с ними производится через методы. Это называется инкапсуляцией.
Вынос бизнес логики (поведения) из ЛЮБОГО ОБЪЕКТА с открытием полей наружу нарушает инкапсуляцию и это уже объектом не является.
ИЛ
> Как бы объяснить.
Модель сама по себе минималистична. Она знает откуда взять данные, в каком виде отдать их, и в каком засунуть обратно в базу.
Вы зациклены на Eloquent. И словом "модель" снова и снова называете голую структуру данных без поведения со строкой из БД, которую передаёте своим сервисам-процедурам.
> Вынесение БИЗНЕС-ЛОГИКИ из МОДЕЛИ не нарушает ООП!
Объект состоит из состояния и поведения, инкапсулированного внутри.
Если есть только данные и нет поведения, то это не объект, а структура данных.
Если есть только поведение и нет состояния, то это функция или процедура как любой ваш сервис.
В полноценном объекте состояние (поля) спрятаны и работа с ними производится через методы. Это называется инкапсуляцией.
Вынос бизнес логики (поведения) из ЛЮБОГО ОБЪЕКТА с открытием полей наружу нарушает инкапсуляцию и это уже объектом не является.
Модель сама по себе минималистична. Она знает откуда взять данные, в каком виде отдать их, и в каком засунуть обратно в базу.
Вы зациклены на Eloquent. И словом "модель" снова и снова называете голую структуру данных без поведения со строкой из БД, которую передаёте своим сервисам-процедурам.
> Вынесение БИЗНЕС-ЛОГИКИ из МОДЕЛИ не нарушает ООП!
Объект состоит из состояния и поведения, инкапсулированного внутри.
Если есть только данные и нет поведения, то это не объект, а структура данных.
Если есть только поведение и нет состояния, то это функция или процедура как любой ваш сервис.
В полноценном объекте состояние (поля) спрятаны и работа с ними производится через методы. Это называется инкапсуляцией.
Вынос бизнес логики (поведения) из ЛЮБОГО ОБЪЕКТА с открытием полей наружу нарушает инкапсуляцию и это уже объектом не является.
В ларе у модели по дефолту есть поведение
ИЛ
Это методы, которые даёт элок для взаимодействия с БД
И
типа такого
И
делает одно действие только
И
Что за классы-команды?
Вообще я за то, чтобы каждый участок кода делал то, для чего он предназначен.
В частности, задача контроллеров - контроллировать, валидаторов - валидировать, моделей - содержать инфу об инстансе записи БД, а сервисов - отвечать за бизнес-логику. Это если упрощённо.
Вообще я за то, чтобы каждый участок кода делал то, для чего он предназначен.
В частности, задача контроллеров - контроллировать, валидаторов - валидировать, моделей - содержать инфу об инстансе записи БД, а сервисов - отвечать за бизнес-логику. Это если упрощённо.
И
