нужен сервис по идеи и в нем уже репозиторий . controller->service->repository
Зачем поверх Ef репа?
как минимум что бы не дергать saveChange каждый раз
Я уже совсем запутался) Так может репа сохранять данные или нет сама, т.е вызывать saveChanges? По идее вызывать сохраниени должен именно сервис, т.е репой ты что-то добавил, удалил, обновил, а изменения комитит сервис.
Велик шанс забыть вызвать коммит проще сделать так если несколько вызовов репы то просто в транзакцию обернуьт внутри сервиса
кал
А вы не путаете коммиты и сейвченджес?
Возможно слово просто не то использовал, я имел ввиду именно сейвченджес.
Есть разные подходы к этому, по сути не имеет значения как вы делаете, имеет значение что то что вы делаете должно быть хоть как то осмысленно и приносить хоть какую то пользу, хоть кому нибудь.
Между сервисом и репозиторием по хорошему бы использовать паттерн UnityOfWork
Забудьте об этих паттернах уже. Единственное, где они могут иметь место - это старый говнокод. Это даже не прошлый век, это прошлое тысячелетие.
Зря вы так, паттерны примененные там где нужно часто выручают. Другое дело это впихивание паттернов ради впихивания а не ради пользы.. Это в последнее время процветает прям
Вырвали из контекста. Я конкретно об UoW/Repository, называя их "этими".
Ну а если dapper используется на проекте, а не ef?
Пользуйтесь атомарными абстракциями. Или попробуйте Vertical Slice.
А разве UnityOfWork это не про атомарность?
Unit* Нет, он больше про инкапсуляцию
Но все равно он про атомарность) Даже если больше про инкапсуляцию
Позвольте я сошлюсь на эту статью, конкретнее в раздел "Шаблоны проектирования для сохраняемости данных". Перевод так себе, лучше наверное читать в оригинале https://learn.microsoft.com/ru-ru/ef/ef6/fundamentals/testing/testability-article#design-patterns-for-data-persistence
Позвольте тогда перефразировать, раз уж термин 'atomic/atomicity' слишком тесно связан с РБД. Упрощая: имелось в виду, что можно вместо Repo использовать другой набор абстракций - эдакий Object Per Query подход.
Я хотел было на него сослаться, но язык не повернулся
Имхо для CRUD-операций CQS избыточен. Но сами по себе подобные подходы отлично проявляют себя. Полностью согласен.
CRUD - это единичный юзкейс. Не припомню ни одного среднего-крупного проекта, где был бы только CRUD.
Согласен, я говорю лишь о том, что вижу со своей колокольни - с колокольни джуна без коммерческоко опыта)
В крупных проектах обычно в нашей сфере как минимум (в других может быть иначе) КРУДЫ занимают 80 а то и более процентов проекта. Просто для информации, и да ессно не только они есть, но чтобы тяжелая логика могла работать кто то должен в крудах данные навносить )))
Обсуждают сегодня