Антон Р., если вы делаете по Елисееву, то он разделяет данные на чтение и изменение состояния (ударение, создание, редактирование).
Поэтому и доменный слой отделяется от отображения. В сущности и репозитории остаётся только то, что нужно для изменения состояния, а что для чтения отдельно. У него это разделано на папки model(изменение состояния) и ReadModel на чтение.
Вот как раз в ReadModel вы и создаёте свой репозиторий (Fetcher) и свою модель для отображения данных ModelView и там же SearchForm(Filter)...
Но в ReadModel можно и не делать ModelView а выводить данные прямо массивом model[id] либо Vue.js или другим Frontend....
Если вы имеете ввиду нельзя изменить данные вчерашнего дня, то это AccessFilter.
Если вы не хотите, чтобы данные в поле нельзя было ввести вчерашнего дня в ручную, то это вопрос валидации. Сравниваете текущий день и дату из поля. Если больше, то не пропускает валидация.
Maksim86, да) Можете и в корень её перекинуть. Но надо вникнуть в правила htaccess. Изучите и поймёте как сделать. Но пока я не вижу смысла переносить) тем более вы переносите не в корень, а во frontend/uploads. Тогда лучше пусть она будет в web
vitaly_74, если вам не нужно как все - то зачем спрашивайте у всех?
Я вам не тыкаю носом. Я говорю, что у вас вопрос, скорее всего, связан не с кэшем, а с запросами в базу данных. Так как кэша я тут вообще не вижу. Поэтому я вас направляю в документацию изучить связи и жадную загрузку.
Вы сами даже в вопросе пишите по бд, а в тексте какой-то кэш. Разберитесь что вам нужно. Я помогу. Как можно выполнять частые кэшированные запросы в бд???????? Кэширование и есть для того, чтобы эти запросы не выполнять!!!! По вопросу уже понятно, что вы ничего не понимаете, а пытаетесь умничать.
Дмитрий, теперь понял. Вам не надо учитывать вообще операции перевода со счета на счёт! Это ни к чему. У вас простой Учет средств, а не денежная система пользователя! Соотвественно изменить баланс счета вы можете даже вручную зайти в счёт и поменять остаток (колонка total). Так же это можно сделать программно! Переводим со счета на счёт. На одном счете уменьшаем столбец на эту сумму, на другом увеличиваем. Не надо никаких операций. Операции у вас не для этого.
Если у вас iPhone можете посмотреть как сделано это в приложении деньги плюс плюс в app stor Деньги Плюс Плюс — Vladimir Shutyuk
Спорить с босом не собираюсь) Пример, действительно, не совсем удачный. Сунул первый попавшийся из поисковика даже не смотрев. И мой пример лиш в комментарии, а не в ответе, который претендует на решение. Откуда такие страсти?
Дмитрий, нет. Если я все правильно понял как вы описали, то категория будет пустая. Какую вы можете сделать категорию, если у вас это просто перевод денег с одного счета на другой? Конечно, можно придумать какую-то категорию типа «корректировка», но зачем она нужна? Предствьте что вместо категории какой-то товар, а не категория. И вы говорите, что при переносе средств из Карты на кошелёк вам нужно создать какой-то дефолтный товар))
Нет. Не нужно. У вас просто выводится тип операции без категории.
Вы продумайте немного как вы видите это в жизни и будет проще.
По правильному я бы мыслил так:
1. Есть таблица счетов
2. Есть таблица операций по счёту.
Человек заводит два новых счёта «карта» и «яндекс кошелёк». Изначально там нулевой баланс.
Далее человек выбирает счёт карта и заносит в него операцию «внесение наличных». Никакая категория не указывается. У нас на балансе 1000 рублей.
Затем человек расходует эти деньги на хлеб. Создаёт операцию в карте с категорией «продукты» с типом «расход» на сумму 100 руб. Название «хлеб».
На балансе 900 руб.
Затем он решил перевести 900 рублей на кошелёк. Переходит в счёт карта и нажимает перевести между счётами. Выбирает счёт текущий (или уже выбран программно) и куда перевести. Указывает сумму перевода 900 руб.
Далее вносим две записи:
1. Списание средств с баланса Карты
2. Зачисление средств на баланс счета.
Никакие категории не указываем.
Если мы переносим операцию «хлеб» из одного счета в другой тогда просто переносим данные с той же категорией.
Вроде просто. Не знаю что не понятно)
Надо было лучше дизайн таблиц выложить и описать. Сложно столько текста анализировать и рисовать в голове структуру)
Согласен, хотя бы так... )) Бессмысленно вообще пытаться делать обёртку когда мы живем в 21 веке. Полно открытого исходного кода с решением подобных задач. Некоторые куда получше и гибче.
Дмитрий, можно и добавить два transfer_type, transfer_id
В transfer_type указывать Яндекс кошелёк, в transfer_id указывать запись транзакции. но при вашем подходе это особого смысла не имеет. Так как таблица одна работает
1. Добавить новый тип "перевод между счетами"
2. Добавить новую колонку transfer_id (ID счёта в базе)
Тогда получаем:
1. ID -1 Счет карты Visa 1000 руб.
2. ID -2 Яндекс кошелёк 0 руб.
Переводим с Карты на кошелёк 1000 руб. Указываем тип "перевод между счетами" в колонку "transfer_id" помещаем на счет, который осуществлен перевод В данном случае transfer_id = 1.
Далее при каждом редактировании, отслеживаем эти данные кошелька. Если важна функция жёсткой привязки, то вместо ID типа счёта помещаем туда ID записи. При удалении этой операции лезем в базу и ищем все записи в transfer_id == ID. Если нашли - удаляем. При изменении - изменяем данные.
Поэтому и доменный слой отделяется от отображения. В сущности и репозитории остаётся только то, что нужно для изменения состояния, а что для чтения отдельно. У него это разделано на папки model(изменение состояния) и ReadModel на чтение.
Вот как раз в ReadModel вы и создаёте свой репозиторий (Fetcher) и свою модель для отображения данных ModelView и там же SearchForm(Filter)...
Но в ReadModel можно и не делать ModelView а выводить данные прямо массивом model[id] либо Vue.js или другим Frontend....