Как реализовать суммарный остаток продуктов по всем активным складам в Laravel?

Question

[Евгений]

Всем привет.
Дано: интернет магазин с несколькими складами. Некоторые склады имеют возможность продажи продуктов с сайта, по некоторым из складов остаток в карточке товара должен показываться справочно.

Модели/таблицы:
Product - продукт, "Платье синее"

Size - размеры продуктов, "S", "M" и прочее

Stock - склад "Основной склад". Содержит в себе bool признак "active", который отвечает за возможность продажи продукта с этого склада в интернет магазине

StockBalance - таблица, содержащая в себе id продукта, id склада, id размера и кол-во.

Вопрос: как построить запрос, чтобы получить по продукту сумму всех количеств продукта на складах, которые имеют признак "active", т. .е. на складах, на которых возможна продажа из интернет магазина.
Также может быть стоит построить модель по остаткам как-то по-другому?

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

Answer 1

[Daniil Vasilyev]

SELECT p.*, SUM(sb.count)
FROM Product AS p
JOIN StockBalance AS sb ON sb.product_id = p.id
GROUP BY p.id;

А запрос должен быть в репозитории или в сервисе для продуктов (но лучше сервисы держать для бизнес-логики, чем для запросов). И уже оттуда вызываться в контроллере.
https://www.larashout.com/how-to-use-repository-pa...
https://laravel.demiart.ru/repository-design-pattern/

Comments

[vism]

Репозитарий с элокуентом?
Гм.. извращенцы

[Daniil Vasilyev]

vism, репозитории в принципе подразумевают разные виды запросов, хоть через QueryBuilder, хоть через чистый SQL, в этом ничего плохого нет, по крайней мере по практикам из Java/C#

[vism]

Daniil Vasilyev, именно так, а то, что вы предлагаете завязывается на модель элокуент, которая сама по себе очень похожа на репозиторий :)

модели элокуент это репозиторий через призму восприятия элоуента )))

Разве это не шедевр идуского стиля?:)
Можно рекурсивно создавать такие классы:)

namespace App\Repositories;

use App\Post;

class PostRepository implements PostRepositoryInterface
{
    /**
     * Get's a post by it's ID
     *
     * @param int
     * @return collection
     */
    public function get($post_id)
    {
        return Post::find($post_id);
    }

    /**
     * Get's all posts.
     *
     * @return mixed
     */
    public function all()
    {
        return Post::all();
    }

    /**
     * Deletes a post.
     *
     * @param int
     */
    public function delete($post_id)
    {
        Post::destroy($post_id)
    }

    /**
     * Updates a post.
     *
     * @param int
     * @param array
     */
    public function update($post_id, array $post_data)
    {
        Post::find($post_id)->update($post_data);
    }
}

[jazzus]

Метод all который возвращает all и get который возвращает find нужно постить в категории юмор. Не хватает еще методов getCollection с методом get и getModel который будет резолвить класс модели. Вообще тема репозиториев холиварная и юморная. Т.к. четких инструкций нет профи пишут свои велосипеды (чаще всего с говнокодом) и никому их не показывают. Чтобы не раскрывать крутые идеи. При этом фреймворк не используют. Если фреймворк использовать у тебя и так контроллеры будут чистые. А если классов Ларавел не хватает то выносить нужно с включением головы и с необходимостью выноса. Т.е. повторяемые данные, для улучшения читаемости, отдельные сервисы со своей задачей и ответственностью. А не код ради кода и вынос ради выноса. Зачем в этих статьях клонируют понятные методы Ларавел в свои дебильные варианты непонятно.