Laravel где размещать бизнес логику

У меня вопрос более общего характера, с которым я столкнулся в процессе разработки приложения.

Где нужно размещать бизнес логику приложения?
Перечитал разные статьи и все они расходятся во мнениях. Одни пишут что в моделях, следуя принципу «худых» контроллеров, другие пишут, что модели отвечают только за работу с полями БД.

Для примера, в моем проекте (интернет-магазин) присутствует фильтр товаров. Вот он используется (пока что) только в контроллере категорий, работает только с таблицами продуктов и параметров. Я выделил класс фильтра в отдельную директорию именуемую Filters (да, там их несколько разных).

Вопрос:
1. На сколько правильно я сделал (и правильно ли вообще)?
2. Все же, куда помещать такие вот моменты бизнес логики?

Заранее благодарю за ответы!
Всем хорошего и продуктивного дня!

• Вопрос задан более трёх лет назад
• 4417 просмотров

2 комментария

Простой 2 комментария

в ларавел модели используются только для работы с базой данных, а всю бизнес-логику перемещают в специальные классы «service layer», которые подключают через dependency injection

Грамотное ООП: организация надёжной бизнес-логики / Дмитрий Елисеев (ElisDN)

Barmunk, из примера не очень ясно кто в контроллер вкладывает нужный сервис. Можете пояснить своими словами или статьёй? Я делаю так: Есть Middleware UsersController UsersService UsersModel. Бизнес логика в сервисе, контроллер отвечает за валидацию и ответы, а самая худая это модель при этом чаще всего не превышая 10 строк кода.

Решения вопроса 1

Мое мнение, что в модельках должна быть логика только связанная с получением данных с базы. Бизнес логика, пишется в отдельных сервис классах, как у вас, например, класс фильтр.

Иначе модель будет расти до тысяч строк кода, и будет мешаниной методов. Принцип же класса в ооп любого, это узкая специализация над одной задачей. Задача модели получать данные с базы, и туда их записывать.

Контроллер же просто дерижер, который принимает запрос, обрабатывает, дергает нужные методы приложения, и отдает ответ. Сложной логики в нем писать не нужно

Ответ написан более трёх лет назад
Нравится 8 9 комментариев

Про контроллер — правильно, про модель — нет.
JhaoDa, Поделись как надо)
NubasLol спасибо за ответ!
Иван, по определнию, ну не обязательно бд, можешь хоть в файл записывать

Иван, С чего бы это было моделью?

NubasLol, есть такая практика тонкие контроллеры толстые модели, но не нужно все сводить в абсолют.
Тут у нас модель это реализация active record и в ней может быть логика, но нужно понимать, что за логику вы туда пишите. Работа с данными? это можно, но не нужно писать логику сохранения файла в модели, для этого есть сервисы. Иными словами в модели можно писать логику, но модель должна отвечать только за свои данные, надеюсь суть понятна.

PS. Модель слияние сущности с репозиторием.

Куда вынести логику из controllers, commands, jobs. Лучшие практики Laravel разработчиков

Артур, слишком много тезисов в одном сообщении, чтобы однозначно согласиться или нет.

Модель — это, в общем смысле, функция, т.е. некий механизм, делающий что-то. Когда-то он укладывается в один класс, когда-то нет. Когда-то она является отражением БД, когда-то — API, когда-то — сборной солянки.
Если модель является агрегатом, то она отвечает и за всё, что агрегирует.
Если мы посмотрим на доктрину, то сущности (модели) от репозиториев (и слоя хранения вообще) отделены явным образом.

NubasLol, Ваше мнение мне близко. В Ларавеле так построены модели, что они скорее содержат «настройки» конкретной таблицы БД, чем бизнес логику. Поэтому логику тоже стараюсь переносить в отдельные классы.

Но бывает, что такой вот вспомогательный класс (возьмем тот же Filter) связан с конкретной таблицей БД и, следовательно, конкретной моделью. Как Вы поступаете в данном случае: оформляете этот отдельный класс как трейт, или наследуете от модели, или вообще их жестко не связываете?

Потому что иногда надо же, например, получить список фильтров согласно какой-нибудь особенной логике, и хочется написать что-то типа Filter::getAvailable(). Но если метод getAvailable() у нас в другом классе, то надо уже другой класс вызывать (понятно, что и в ServicesFilter::getAvailable() нет ничего крамольного, но все же).

SVZhidkow, фильтр пишу в самой моделе, так как он относится к получению данных.

Делаю скоп, в который передается массив, с данными для фильтрации.

Есть сервис класс фильтр, в котором есть методы, для общих фильтров, например, например по дате, и в моделке просто вызывается метол этого сервиса.

А если нужен метод не общий, то пишется просто в самой модели

Ответы на вопрос 2

Изначально затея MVP была в этом:
View должно было быть представлением данных, глупым представлением, которое всего лишь смотрит на изменения полей Model и обновляет вид для юзера
Controller должен был отвечать за ввод и вывод информации пользователю. Никакой бизнес логики — лишь команды и ответы.
Model должен был быть представлением данных. Это не значит, что модели должны быть «толстыми» — это значит, что должны быть другие части приложения, отвечающие за бизнес логику. Не модель. И уж точно не та «модель», наглухо связанная с базой данных.

А теперь мое имхо:
1. Контроллеры принимают запрос, валидируют, достают авторизированного юзера, проверяют пермишены. Вызывают ОДИН метод какого-то класса, форматируют результат и отдают.
2. В моделях только логика БД. Никакой бизнес логики от слова «совсем». Никаких зависимостей. Ничего.

Всю логику выносить куда-то. Логика не должна знать о том, что это HTTP — и.е. никаких обьектов HTTP запросов, никаких HTTP ответов, никаких HTTP ошибок. Если нужен 404 — создается эксепшен под юс кейс (типа UserNotFoundException), а в контроллере ловится и переделывается в NotFoundHttpException. Никак иначе.

Ответ написан более трёх лет назад
Нравится 2 3 комментария

никаких обьектов HTTP запросов

а как тогда делать добавление в бд из формочки на странице?

JohnDaniels, передавать в класс все данные вручную. $request->all() и подобное тоже не катит.
Спасибо за ответ!

По моему мнению, бизнес логика как раз и должна быть размещена в модели. Большая ошибка считать, что модель отвечает за работу с базой данных. Это же не коннектор базы данных.
Вся эта путаница возникает из-за того, что многие моменты предметной области пересекаются со структурой базы данных. Те же самые отношения между моделями конечно, позволяют удобно формировать сложные запросы, но в первую очередь хорошо отражают взаимосвязи внутри предметной области.
Кроме того, многие инструменты, которые дают фреймворки для работы внутри модели (события, доступ к старым данным, сеттеры/геттеры и др.) как минимум упрощают последующее понимание кода, резко ускоряют последующие дополнения и отладку.
Чтобы не запутаться в слишком толстой модели лучше всего каждый перед созданием нового метода задуматься: а нельзя ли его реализовать как квери билдер, геттер/сеттер или еще какой-то документированный метод фреймворка. Ну и конечно, никто не мешает из модели вынести какую-то объемную задачу в какой-нибудь выделенный сервис.
В итоге, из различных контроллеров можно просто запрашивать отдельные свойства модели, присваивать им значения. А вся сложная логика будет сконцентрирована в модели. И не нужно будет каждый раз переворачивать на изнанку весь код, если бизнес-логика немного меняется.

Ответ написан 13 мар.
Комментировать
Нравится Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

• Node.js
• +1 ещё

Как сделать рассылку «ползучей»?

• 2 подписчика
• 24 мая
• 95 просмотров

Источник: qna.habr.com

Куда размещать бизнес логику приложения laravel?

Перечитал разные статьи и все они расходятся во мнениях — да здесь будет тоже самое: что ни ответ, то мнение. Тема как повод потрести воздухом.

– user256824
31 мая 2019 в 7:33

Laravel — это всего навсего инструмент для разработки, что и где размещать зависит только от тебя (каждый по разному воспринимает абстракцию). Создавай свои фасады, выноси в отдельные файлы, делай код более простым. Ведь лучше открыть один файл с классом Filter чем искать по всему проекту остальные.

31 мая 2019 в 9:13
Спасибо всем за ответы. Учту.
31 мая 2019 в 9:28
31 мая 2019 в 9:32

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Хороший вопрос, и, как показывают комментарии, далеко не всем понятный.

Главное, что надо понимать, услышав аббревиатуру MVC — что термин Model носит двусмысленный характер. Он может означать как всю бизнес логику приложения (правильно), так «только работу с полями БД» (массовое застарелое заблуждение пользователей похапе). Как только в голове устаканивается правильный вариант, тут же все встает на свои места. Главное тут понимать, что модель, это не класс для работы с БД, а вся бизнес-логика приложения, разумеется, разбитая на множество слоев и уровней.

Вот короткое пояснение всей системы, на английском, так что перескажу своими словами. Очень хорошо эту тему также раскрывает Дмитрий Елисеев в своих докладах на конференциях и обучающих видео — настоятельно рекомендую.

В двух словах, есть приложение и есть интерфейсы. Приложение одно — интрефейсов много. В докладе на PHPRussia Дмитрий насчитал 5, и это еще не предел:

• веб-контроллер, который рисует форму
• REST контроллер, который отдает тупо JSON
• вебхук контроллер, который принимает данные из CRM
• консольная утилита
• сервис очередей

ВСЕ эти интерфейсы могут быть использованы для интеракции с внешним миром и выполнения одной и той же задачи. Именно поэтому никакой, ни малейшей бизнес-логики в них быть не должно, или тут же начнется дублирование кода. Поэтому надо отличать интерфейсы от собственно приложения.

• Контроллер. Это просто интерфейс. Прислуга. Взять данные из НТТР запроса и передать их в соответствующий метод настоящей модели. Чисто «подай-принеси». Если какая логика в контроллере есть — то только связанная с обработкой формы или запроса. Скажем, проверить заполненность полей, совпадение паролей и пр. После получения ответа из модели отправить нужные НТТР заголовки — куки, сессия, локейшен — вот это вот всё.
• Модель. Состоит из нескольких слоев

• сервис или хелпер. Тот код, который обычно пишется в толстом контроллере. Собственно код приложения, без упора на работу с БД. К примеру, если мы хотим зарегистрировать пользователя, то у нас должен быть сервисный слой Пользователь, у которого есть метод register(). И вот этот вот метод мы и вызываем хоть из контроллера, хоть из консольной утилиты, хоть из вебхука.
• слои для работы с БД
• их может быть много. Может быть вырожденная «модель» (в плохом смысле этого слова), тупо класс, в методах которого написаны SQL запросы на все случаи жизни.
• может быть целая иерархия — для простых запросов ORM, для более сложных — репозиторий.

Если говорить о конкретно этом случае, то фильтры — это работа контроллера, поскольку это НТТР запрос. Дело контроллера обработать все поля, вытащить из них осмысленную информацию и запросить метод сервиса товаров с теми данными, по которым надо делать запрос.

Разумеется, если работа с фильтрами может производиться в разных контроллерах, то разумно вынести ее в отдельный сервис. Соответственно, в контроллере будет два обращения — один к сервису фильтров, второй — к модели.

Источник: ru.stackoverflow.com

MVC (Laravel) где добавить логику

Скажем, всякий раз, когда я выполняю операцию CRUD или изменяю отношения определенным образом, я также хочу сделать что-то еще. Например, всякий раз, когда кто-то публикует сообщение, я также хочу что-то сохранить в таблице для аналитики. Может быть, не лучший пример, но в целом там много этой «сгруппированной» функциональности.

Обычно я вижу, что этот тип логики помещается в контроллеры. Это все прекрасно, что денди, пока вы не захотите воспроизвести эту функциональность во многих местах. Когда вы начинаете попадать в частичные, создавая API и создавая фиктивный контент, это становится проблемой с сохранением вещей DRY.

Способы, которые я видел для управления, это события, репозитории, библиотеки и добавление к моделям. Вот мое понимание каждого из них: Службы: Это место, где большинство людей, вероятно, поместит этот код.

Моя основная проблема с услугами заключается в том, что иногда трудно найти в них определенную функциональность, и я чувствую, что их забывают, когда люди сосредоточены на использовании Eloquent. Как я узнаю, что мне нужно вызвать метод publishPost() в библиотеке, когда я могу просто сделать $post->is_published = 1 ? Единственное условие, по которому я вижу, что это хорошо работает, — это ТОЛЬКО использовать службы (и в идеале сделать Eloquent недоступным каким-то образом из контроллеров все вместе).

В конечном итоге кажется, что это просто создаст кучу лишних ненужных файлов, если ваши запросы обычно следуют вашей структуре модели. Хранилища: Из того, что я понимаю, это в основном как сервис, но есть интерфейс, поэтому вы можете переключаться между ORM, что мне не нужно.

События: Я считаю это самой элегантной системой в некотором смысле, потому что вы знаете, что ваши модельные события всегда будут вызваны методами Eloquent, поэтому вы можете написать свои контроллеры, как обычно. Я вижу, что они становятся грязными, и если у кого-то есть примеры больших проектов, использующих события для критической связи, я бы хотел это увидеть.

Модели: Традиционно у меня были бы классы, которые выполняли CRUD, а также обрабатывали критическую связь. Это действительно облегчило работу, потому что вы знали всю функциональность вокруг CRUD +, что бы ни было, с ней было. Простой, но в MVC-архитектуре это обычно не то, что я вижу.

В некотором смысле, хотя я предпочитаю этот сервис, потому что его немного легче найти, и есть меньше файлов для отслеживания. Тем не менее, это может быть немного дезорганизовано. Я хотел бы услышать обхода этого метода и почему большинство людей не делают этого. Каковы преимущества/недостатки каждого метода? Я что-то пропустил?

Sabrina Leggett 11 май 2014, в 15:31
Поделиться
Вы можете минимизировать свой вопрос?
The Alpha 11 май 2014, в 17:52
Также вы можете проверить это .
The Alpha 11 май 2014, в 17:55

«Откуда мне знать, что мне нужно вызывать метод publishPost () в библиотеке, когда я могу просто сделать $ post-> is_published = 1?» Документация?

ceejayoz 15 апр. 2016, в 15:46
одна из красот о eloquent и ORMS — с ними проще работать без большого количества документов?
Sabrina Leggett 15 апр. 2016, в 16:28

Спасибо за публикацию этого. Я борюсь с теми же вопросами и считаю ваш пост и ответ невероятно полезным. В конечном итоге я решил, что Laravel не предоставляет хорошую архитектуру для чего-либо, что выходит за рамки быстрого и грязного сайта Ruby-on-Rails. Торгует повсюду, с трудом находит классовые функции и тонны автомагического мусора повсюду. ORM никогда не работал, и если вы используете его, вы, вероятно, должны использовать NoSQL.

Alex Barker 21 дек. 2018, в 00:28
Показать ещё 3 комментария
Поделиться:
design-patterns

4 ответа

Я думаю, что все шаблоны/архитектуры, которые вы представляете, очень полезны, если вы следуете принципам SOLID.

Для того, чтобы добавить логику, я думаю, что важно ссылаться на принцип единой ответственности. Кроме того, в моем ответе вы полагаете, что работаете над средним/крупным проектом. Если это проект throw-something-on-a-page, забудьте этот ответ и добавьте все его в контроллеры или модели.

Короткий ответ: Где это имеет смысл для вас (со службами).

Контроллеры. В чем ответственность Контроллеров? Конечно, вы можете поместить всю свою логику в контроллер, но это ответственность диспетчера? Я так не думаю.

Для меня контроллер должен получить запрос и вернуть данные, и это не место для размещения проверок, методов вызова db и т.д.

Модели. Является ли это хорошим местом для добавления логики, например, отправки приветственного сообщения, когда пользователь регистрирует или обновляет количество голосов в почте? Что делать, если вам нужно отправить тот же адрес электронной почты из другого места в вашем коде? Создаете ли вы статический метод? Что, если эти письма нуждаются в информации из другой модели?

Я думаю, что модель должна представлять сущность. С Laravel я использую только класс модели, чтобы добавить такие вещи, как fillable , guarded , table и отношения (это потому, что я использую шаблон репозитория, иначе модель также имела бы save , update , find и т.д.).

Репозитории (шаблон хранилища). В начале я был очень смущен этим. И, как и вы, я подумал: «Хорошо, я использую MySQL, и это так».

Однако я сравнил плюсы и минусы использования шаблона репозитория, и теперь я его использую. Я думаю, что сейчас, в этот самый момент, мне нужно будет только использовать MySQL. Но, если через три года мне нужно перейти на нечто вроде MongoDB, большая часть работы будет выполнена. Все за счет одного дополнительного интерфейса и $app->bind(«interface», «repository») .

События (Шаблон наблюдателя): События полезны для вещей, которые могут быть брошены в любой класс в любое время. Подумайте, например, о отправке уведомлений пользователю. Когда вам нужно, вы запускаете событие для отправки уведомления в любом классе вашего приложения. Затем вы можете иметь класс типа UserNotificationEvents , который обрабатывает все ваши запущенные события для уведомлений пользователей.

Услуги. До сих пор у вас есть выбор, чтобы добавить логику к контроллерам или моделям. Для меня имеет смысл добавить логику в Services. Позвольте мне взглянуть на это, Services — это причудливое название для занятий. И у вас может быть столько классов, сколько имеет смысл для вас в ваших приложениях.

Возьмем этот пример: недавно я разработал нечто вроде Google Forms. Я начал с CustomFormService и закончил с CustomFormService , CustomFormRender , CustomFieldService , CustomFieldRender , CustomAnswerService и CustomAnswerRender . Зачем? Потому что это имело смысл для меня. Если вы работаете с командой, вы должны поместить свою логику там, где это имеет смысл для команды.

Преимущество использования Services vs Controllers/Models заключается в том, что вы не ограничены одним контроллером или единой моделью. Вы можете создать как можно больше услуг на основе дизайна и потребностей вашего приложения. Добавьте к этому преимущество вызова службы в любом классе вашего приложения.

Это длится долго, но я хотел бы показать вам, как я структурировал свое приложение:

app/ controllers/ MyCompany/ Composers/ Exceptions/ Models/ Observers/ Sanitizers/ ServiceProviders/ Services/ Validators/ views (. )

Я использую каждую папку для определенной функции. Например, каталог Validators содержит класс BaseValidator , отвечающий за обработку валидации на основе $rules и $messages конкретных валидаторов (обычно по одной для каждой модели). Я мог бы легко поместить этот код в Сервис, но для меня имеет смысл иметь определенную папку для этого, даже если он используется только в службе (пока).

Я рекомендую вам прочитать следующие статьи, поскольку они могут объяснить вам немного лучше:

Нарушение формы Dayle Rees (автор CodeBright): Здесь я собрал все это вместе, хотя я изменил несколько вещей, чтобы соответствовать моим потребностям.

Развязка вашего кода в Laravel с использованием репозиториев и сервисов Chris Goosey: В этом сообщении хорошо объясняется, что такое «Сервис» и «Шаблон репозитория» и как они сочетаются.

У Laracasts также есть Хранилища упрощенные и Отдельная ответственность, которые являются хорошими ресурсами с практическими примерами (хотя вы должны заплатить).

Luís Cruz 14 авг. 2014, в 03:23
Поделиться

отличное объяснение. Вот где я сейчас нахожусь — в текущем проекте я вкладываю свою бизнес-логику в модели, и на самом деле она работает очень хорошо. Нам определенно нужно немного выдумать SOLID, но это еще не доставило нам проблем. Это быстро, немного грязно, но пока наш проект очень ремонтопригоден, потому что он СУХОЙ. Я определенно согласен с тем, чтобы придерживаться их в данный момент, потому что они выполнили свою работу, но в любом будущем проекте я, вероятно, просто пойду с тем, что является стандартным, что, как кажется, стало репозиторием.

Sabrina Leggett 14 авг. 2014, в 16:49

Я рад, что вы нашли способ, который имеет смысл для вас. Просто будьте осторожны с предположениями, которые вы делаете сегодня . Я работал над проектом более 3 лет и в итоге получил контроллеры и модели с 5000+ строками кода. Удачи с вашим проектом.

Luís Cruz 14 авг. 2014, в 17:08

также немного грязный, но я думал об использовании черт, чтобы избежать огромных моделей. Таким образом, я могу немного выделить их

Sabrina Leggett 14 авг. 2014, в 17:09

Эта статья хорошо формулирует, КОГДА имеет смысл пользоваться услугами. В вашем примере формы имеет смысл использовать сервисы, но он объясняет, как он это делает, то есть когда логика напрямую связана с моделью, которую он помещает в эту модель. justinweiss.com/articles/where-do-you-put-your-code

Sabrina Leggett 13 апр. 2016, в 21:09
Показать ещё 2 комментария

То, что я использую, чтобы создать логику между контроллерами и моделями, — это создать сервисный уровень. В принципе, это мой поток для любых действий в моем приложении:

• Контроллер получает запрашиваемое пользователем действие и отправляет параметры и делегирует все в класс обслуживания.
• Класс обслуживания выполняет всю логику, связанную с операцией: проверка ввода, ведение журнала событий, операции с базой данных и т.д.
• Модель содержит информацию о полях, преобразовании данных и определениях валидации атрибутов.

Вот как я это делаю:

Этот метод контроллера создает что-то:

public function processCreateCongregation() < // Get input data. $congregation = new Congregation; $congregation->name = Input::get(‘name’); $congregation->address = Input::get(‘address’); $congregation->pm_day_of_week = Input::get(‘pm_day_of_week’); $pmHours = Input::get(‘pm_datetime_hours’); $pmMinutes = Input::get(‘pm_datetime_minutes’); $congregation->pm_datetime = Carbon::createFromTime($pmHours, $pmMinutes, 0); // Delegates actual operation to service. try < CongregationService::createCongregation($congregation); $this->success(trans(‘messages.congregationCreated’)); return Redirect::route(‘congregations.list’); > catch (ValidationException $e) < // Catch validation errors thrown by service operation. return Redirect::route(‘congregations.create’) ->withInput(Input::all()) ->withErrors($e->getValidator()); > catch (Exception $e) < // Catch any unexpected exception. return $this->unexpected($e); > >

Это класс службы, который выполняет логику, связанную с операцией:

public static function createCongregation(Congregation $congregation) < // Log the operation. Log::info(‘Create congregation.’, compact(‘congregation’)); // Validate data. $validator = $congregation->getValidator(); if ($validator->fails()) < throw new ValidationException($validator); >// Save to the database. $congregation->created_by = Auth::user()->id; $congregation->updated_by = Auth::user()->id; $congregation->save(); >

И это моя модель:

class Congregation extends Eloquent < protected $table = ‘congregations’; public function getValidator() < $data = array( ‘name’ =>$this->name, ‘address’ => $this->address, ‘pm_day_of_week’ => $this->pm_day_of_week, ‘pm_datetime’ => $this->pm_datetime, ); $rules = array( ‘name’ => [‘required’, ‘unique:congregations’], ‘address’ => [‘required’], ‘pm_day_of_week’ => [‘required’, ‘integer’, ‘between:0,6’], ‘pm_datetime’ => [‘required’, ‘regex:/([01]?[0-9]|2[0-3]):[0-5]?[0-9]:[0-5][0-9]/’], ); return Validator::make($data, $rules); > public function getDates() < return array_merge_recursive(parent::getDates(), array( ‘pm_datetime’, ‘cbs_datetime’, )); >>

Для получения дополнительной информации об этом способе я использую для упорядочивания моего кода для приложения Laravel: https://github.com/rmariuzzo/Pitimi

Rubens Mariuzzo 11 май 2014, в 17:38
Поделиться

Похоже, что сервисы — это то, что я назвал библиотеками в своем посте. Я думаю, что это лучше, чем репозитории, если вам не нужно использовать несколько ORMS, но проблема в том, что вам нужно перенести весь проект (что вам не нужно делать с событиями), и кажется, что В конечном итоге это просто отражает структуру модели, поэтому у вас есть все эти дополнительные файлы. Почему бы просто не включить его в модели? По крайней мере, так у вас нет лишних файлов.

Sabrina Leggett 12 май 2014, в 14:40
Rubens Mariuzzo 12 май 2014, в 16:57

Меня тоже учили о моделях . было бы неплохо получить хорошее объяснение почему (может быть, проблемы с зависимостями)?

Sabrina Leggett 12 май 2014, в 17:26
Oguzhan 17 май 2014, в 08:23
Rubens Mariuzzo 17 май 2014, в 18:34

Если все, что вы делаете, это $congregation->save(); тогда, возможно, вам не понадобятся репозитории. Однако вы можете увидеть, что ваши потребности в доступе к данным со временем возрастут Вы можете начать нуждаться в $congregation->destroyByUser() или $congregationUsers->findByName($arrayOfSelectedFields); и так далее. Почему бы не отсоединить ваши услуги от потребностей доступа к данным. Позвольте остальной части вашего приложения работать с объектами / массивами, возвращенными из репозиториев, и просто обрабатывать / форматировать / и т. Д. . Ваши репозитории будут расти (но разбить их на разные файлы, в конечном итоге сложность проекта должна где-то находиться).

prograhammer 04 март 2015, в 00:39
Guillemo Mansilla 25 окт. 2017, в 22:26
Показать ещё 5 комментариев

Я хотел опубликовать ответ на свой вопрос. Я мог бы поговорить об этом в течение нескольких дней, но я попытаюсь получить это сообщение быстро, чтобы убедиться, что я его заработал.

Я закончил использование существующей структуры, которую предоставляет Laravel, что означает, что я сохранил файлы в основном как Model, View и Controller. У меня также есть папка Libraries для повторно используемых компонентов, которые на самом деле не являются моделями.

Я НЕ ПЛАНИРУЕТ МОИ МОДЕЛИ В УСЛУГАХ/БИБЛИОТЕКАХ. Все изложенные причины не помогли мне на 100% воспользоваться услугами. Хотя я могу ошибаться, насколько я вижу, они просто приводят к количеству лишних почти пустых файлов, которые мне нужно создавать и переключаться между ними при работе с моделями, а также действительно уменьшать преимущество использования красноречивых (особенно когда речь заходит о моделях RETRIEVING, например, с использованием разбивки на страницы, области и т.д.).

Я поставил бизнес-логику в МОДЕЛИ и получил доступ к красноречивому прямо от моих контроллеров. Я использую ряд подходов, чтобы убедиться, что бизнес-логика не обошла стороной:

Решение проблем с использованием моделей:

• Организация: Да, если вы добавите больше логики в модели, они могут быть длиннее, но в целом я обнаружил, что 75% моих моделей все еще довольно малы. Если я решил организовать более крупные, я могу сделать это с помощью свойств (например, создать папку для модели с дополнительными файлами, такими как PostScopes, PostAccessors, PostValidation и т.д. По мере необходимости). Я знаю, что это не обязательно то, что характерно, но эта система работает без проблем.

Дополнительное примечание. Я чувствую, что обертывание ваших моделей в сервисах похоже на наличие швейцарского армейского ножа с множеством инструментов и создание другого ножа вокруг него, который в основном делает то же самое? Да, иногда вам может понадобиться снять ленту с ленты или убедиться, что два лезвия используются вместе. но обычно есть другие способы сделать это.

Источник: overcoder.net