DTO.
Есть довольно объемный проект. Нужно впилить в проект Soft Delete (мягкое удаление - запись не удаляется, а помечается что-то вроде IsDeleted = true + еще пара свойств, типо кто удалил).
У проекта куча сущностей, надо сделать возможность мягкого удаления для нескольких из них (штук 10).
У проекта есть уровень Core (что-то вроде бизнес логики и уровень бд, дальше там развлетвления на портирование - веб, wpf, xamarin).
Core содержит в себе DTOшки и сервисы (сервисы работают только с DTO - принимают и отдают). Все это дело между собой маппится Automapper'ом. (Сущности и DTO, ну и дальше соответственно).
Идея состоит в том, что есть интерфейс для Soft Delete (выше описал основные свойства). Этот интерфейс имлементиться и для DTO и для Сущностей. Если с вопросом мягкого удаления все хорошо, то с вопросом восстановления после мягкого удаления не очень.
Есть метод Restore<T> (T dto) where T : BaseDTO, ICanSoftRemoval, ....
{
.... какие-то действия .....
Uow.Repository<???> ().Update(Mapper.Map<T, ???> (dto));
}
Относительно того, почему юзается кастомная версия Uow & Repository - приложение работает сразу с 2 база данных (NoSQL & SQL).
Как можно красиво узнать какому типу следует маппить dto и тип репозитория?
- словарь типов, не очень как по мне идея и как-то костыльно слишком...
- передавать в Restore сразу 2 дженерика, тоже не очень, так как метод будет вызываться в более верхнем слое, который в принципе не шарит, что такое база данных и и что там такое.
https://www.thereformedprogrammer.net/ef-core-in-depth-soft-deleting-data-with-global-query-filters/
Спасибо конечно, но я это читал (по крайней мере взглядом пробегал), там нету информации относительно решение мое задачи. С точки зрения базовой имплементации идеи Soft Delete с EF или без него все просто. У меня проблема относительно Automapper'a скорее и взаимодействия слоя логики и базы данных в данном случае. Я ищу вариант элегантного решения задачи - конечно можно написать N методов на Restore любой DTOшки. Но это немного странный подход. Подход с словарем соотношения типом меня тоже не очень радует - тогда резко пропадает одна из функций автомаппера (соотносить типы автоматически). Я описывал проблему максимально подробно, так как возможно кто-то мог предложить идею внесения изменений не в слой логики, а в слой базы данных (напомню, у там юзается 2 базы данных - Mongo и MySQL), именно поэтому паттерн репозиторий и UOW имплементятся кастомно, а не берутся с того же EF'a. Но спасибо за ваше внимание)
Словарь строить автоматически
Подробнее?) Кем строиться? Как вытащить тип сущности которому следует приводить дтошку?
Вот как раз тк две бд, то нужен сервис, который будет строить словарь автоматом, тогда будет пофиг сколько бд, их кстати и на ентити может быть больше одной
Обсуждают сегодня