Обеспечение применения DRY посредством использования двух почти идентичных классов доступа generi c db

Question

Предположим, у меня есть слой бизнес-логики c, в котором я создал нечто похожее на шаблон репозитория. Каждый класс в моем репозитории расширяет один и тот же обобщенный класс c, в котором у меня есть основные c операции CRUD.

Я столкнулся с проблемой, когда мне нужно написать один и тот же лог c для таблиц в моей базе данных, где у меня есть отношение «многие ко многим» - у меня, вероятно, 5 мест в моем ОРМ.

Изначально я думал о том, чтобы поместить эту логику c в класс generi c для принудительного применения DRY - Однако это может быть очень плохой идеей, поскольку мои таблицы «не многие ко многим» также сможет получить доступ к этим указанным c методам.

Другим подходом будет включение этой логики c в каждый из моих классов репозитория, что означает, что тогда мне придется повторять мой код - естественно, мне это не нравится.

Следовательно, это скорее вопрос дизайна. Но мне бы очень хотелось узнать, как вы считаете, что это можно решить, чтобы сделать мой код максимально чистым.

Answer 1

Я бы создал обобщенный c класс хранилища «многие ко многим» и обобщенный c класс хранилища «один ко многим». Это позволяет вам продвигать dry и обеспечивать повторное использование для того же лога c.

Имеет только стандартный базовый класс репозитория, в котором многие ко многим и один ко многим отменяют операции типа crud. Используйте шаблон единиц работы для передачи объектов в общий класс и подклассы репозитория c.

Если вы используете каркас сущностей, тогда dbcontext - это ваша единица работы, а dbset - хранилище. Вам не нужен слой репозитория с каркасом сущностей.

Вот как мы это делаем там, где я сейчас работаю, и он очень чистый. Мы генерируем raw SQL из класса репозитория в зависимости от того, какую базу данных вы используете, например MS Sql, Oracle или DB2. Черт возьми, мы даже делаем это с веб-сервисами, где у нас есть репозиторий веб-сервисов, который передает грубые операции некоторым сторонним приложениям, промежуточному программному обеспечению или автономным сервисам.

Answer 2

Независимо от того, предназначена ли запись для таблицы соединения или нет, обычно это имеет значение только при поиске (поскольку вам необходимо знать, был ли это первичный или составной ключ).

Итак, если вы хотите оставайтесь DRY, вы можете просто использовать метод Entity Framework Find<T>. Он принимает массив значений ключа (который будет иметь только один элемент для таблиц без объединения).

Ссылка: https://docs.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.dbcontext.find

Если вы предпочитаете используйте SingleOrDefault, FirstOrDefault, et c., просто измените ваши методы, чтобы получить параметр Expression<Func<T, bool>> predicate. Затем ваши вызывающие могут указать, как им нужно искать записи.

С другой стороны, если вы добавляете параметр типа к методам вместо класса, вам не нужно иметь набор классов, расширяющих тот же класс - у вас может быть только один класс.