У нас есть заводы по созданию сложных объектов. (For makin 'stuff)PHP шаблоны проектирования Заводы, хранилища и ...?
У нас есть хранилища для их поиска. (Для поиска)
Что мы имеем для их обновления? (Для смены вещей)
Похоже, что недостающая часть в головоломке? Я не думаю, что он принадлежит репозиториям, так как это ломает одну ответственность ...
Обновление объекта (и, следовательно, базы данных) принадлежит репозиторию. Сам репозиторий - это слой между самой базой данных и программой.
Каждая операция базы данных поэтому принадлежит к репозиторию. Кроме того, репозиторий не должен связываться с базой данных, он также может иметь XML, CSV или API в качестве источника данных. Но это не имеет значения, потому что вы общаетесь с репозиторием. Репозиторий имеет дело со всем, что происходит потом.
Вы можете просто изменить репозиторий на другой, и ваша программа будет работать без каких-либо проблем, потому что все хранилища реализуют один и тот же интерфейс. Вам больше не нравится эта база данных MySQL, что старомодный CSV намного лучше? Просто замените использованный репозиторий, и все готово.
Поиск записи в репозитории не более, чем SELECT, поэтому почему вы не должны UPDATE или DELETE?
Дальнейшее чтение на MSDN
Найдено большое объяснение и пример на web.archive.org
Не согласен. Если вы примете эту логику, «поэтому каждая операция базы данных принадлежит репозиторию». вы не можете масштабировать. – AndrewMcLagan
Почему вы не можете масштабировать? У каждого объекта есть собственный репозиторий, поэтому вы масштабируете количество объектов и, следовательно, количество репозиториев, которые вы будете использовать. – KhorneHoly
Подумайте об этом. Отслеживание взаимодействия с базами данных не является единственной причиной для репозиториев. Они «Объекты для получения вещей» ... Это также почему существует шаблон Factory «Объекты для создания сложных вещей». Они могут извлечь выгоду из абстрагирования логики базы данных ... не так, как вы говорите, их единственная причина ... – AndrewMcLagan
Я думаю, что это зависит от подхода.
С DDD, например, вы говорите правду. Репозиторий должен отвечать за добавление, поиск и удаление, поскольку он работает с коллекцией, но возникает вопрос, почему он должен иметь возможность обновлять один объект.
Что можно сделать? Я думаю, что я буду копировать только то, что сказал другой человек, поэтому я просто напишу ссылку для ответа: approach to removing save/update from repository
Интересное примечание к '-> save ($ object)' ... если бы мы пошли с аналогией книжной полки, хотя вы могли бы удалить книгу с полки, вытащите TipEx, чтобы внести некоторые поправки, а затем добавьте ее обратно книжная полка, когда закончите. – CD001
это не обновление. Как вы сказали, это удаление его из коллекции и добавление новых в основном ;-) как насчет идентификатора, например? Это нарушает ситуацию. – mmmm
Объект знает свой собственный идентификатор, и это не меняется - но да, если репо сидит на вершине базы данных и автоматически сохраняется состояние коллекции, это, вероятно, все упадет. – CD001
Не «обновляет» операцию, которая выполняется на самом объекте? Или вы имеете в виду «обновление», как в случае «сохранения существующего объекта с измененным состоянием обратно в хранилище данных»? – David
Вы должны обновить объект, а затем передать обновленный объект обратно в репозиторий; неважно, будет ли ваше репо удерживать объекты в памяти или базу данных, которые вы все еще собираетесь делать как '$ repo-> save ($ object)' – CD001
У нас есть хранилища для сохранения объектов (сложных или нет) , Стойкость включает поиск, но также сохранение (новых или обновленных) объектов (чтобы что-то найти позже). – axiac