Чистая архитектура: инвертирование зависимости EF DbContext

Вы можете определить интерфейс, который предоставляет IQueryable<Person>.

Я думал об этом, но IQueryable<Person> не имеет Add (в отличие от DbSet), и при проверке метод Add не исходит из каких-либо интерфейсов, а реализуется непосредственно в DbSet, поэтому я, к сожалению, до сих пор не вижу, как это сделать. сделать эту работу.

Если вам абсолютно необходимо абстрагироваться от Entity Framework, возможно, вам стоит изучить шаблон репозитория: Learn.microsoft.com/en-us/aspnet/mvc/overview/older-versions‌​/…

@TheHvidsten Мне это «абсолютно не нужно», я учусь, поэтому мне интересно, может ли блестяще выглядящая теория работать на практике, чему сама статья немного противоречит, ссылаясь на репозиторий, который демонстрирует то, о чем в статье не говорится: - Д. Спасибо за ссылку, почитаю немного

@TheHvidsten эта ссылка говорит совсем не об этом. То, что вы предложили, является уродливым антипаттерном. DbContext — это высокоуровневая единица работы с несколькими объектами, а не соединение с базой данных. Помещение поверх него низкоуровневого CRUD-класса полностью нарушает его функциональность как в качестве ORM, так и в качестве отключенного UoW.

@PanagiotisKanavos Я согласен, что это антишаблон, но нежелание правильно использовать Entity Framework не дает много хороших вариантов, поэтому, если вам абсолютно необходимо, то есть много плохих вариантов (отсюда и «абсолютно необходимо»).

Я полностью против размещения классов CRUD поверх DbContext, а вовсе не против правильных репозиториев доменов с несколькими объектами. Однако в случае с ORM, такими как EF, они в конечном итоге становятся тонкими оболочками и контейнерами для запросов. С другой стороны, однообъектные CRUD-классы, которые люди называют «универсальными репозиториями», обычно начинают с нарушения параллелизма, затем реализуют методы, вызывающие удаления, а затем люди приходят сюда и спрашивают, почему их код не работает.

Спасибо за обзор! Если чистая архитектура вокруг EF на практике не достижима, как практически решается эта проблема? Просто игнорировать чистую архитектуру и связать уровень приложения с EF, он же поставщик персистентности?

@karlosss TBH в своих приложениях (если только они не «простые») я склонен использовать EF Core в качестве инструмента уровня «DAL», используемого внутри репозитория, или абстракций CQRS, которые довольно хорошо сочетаются с чистой архитектурой. Конечно, бывают случаи, когда абстракция становится дырявой (например, когда нужно реализовать какую-то сложную логику в транзакционном контексте), но обычно в моих проектах это случалось не так часто. Также обратите внимание, что всегда есть «скрытый» 4-й вариант — шаблоны — это общие рекомендации, а не законы, их можно нарушать.

@GuruStron, случайно, есть ли у вас публичный репозиторий одного из этих приложений, где можно было бы продемонстрировать использование, где я мог бы «получить вдохновение»? Я думаю, что просмотр настоящего работающего кода поможет мне многое понять. Прежде чем нарушить шаблон, я хочу быть уверен, что у меня есть веские причины для этого, потому что, по моему опыту, нарушение шаблонов обычно не заканчивается хорошо :)

«Чистая архитектура» — это название книги, а не образец. Он превратился в общий маркетинговый термин для обозначения связанных идей и книг. Обычное описание узоров — A solution to a problem in a context. То, что работает для конкретной проблемы в одной ситуации (контексте), не обязательно является лучшим решением в другой ситуации. Как правило, это будет очевидно, когда вам понадобятся отдельные модели для EF, уровня приложения и… вашей модели ресурсов REST и API DTO. Хорошая модель базы данных не всегда является хорошим API DTO. Слой Abstractions, используемый для обоих, будет ломаться по мере роста приложения.

Например, шаблон размещенного проекта Blazor создает проект Shared, в который вы помещаете объекты, используемые как сервером, так и клиентом Blazor WASM (GUI). Это очень полезно до тех пор, пока... вам не понадобится добавлять аннотации для добавления проверки в графический интерфейс, что, в свою очередь, влияет на EF. Или осознать, что то, что Required в одной форме, нет Required в другой. Именно так были созданы ViewModels, чтобы удовлетворить потребности различных представлений вместо того, чтобы строить весь графический интерфейс поверх одной модели приложения. Если вы используете OData или GraphQL, аннотации также повлияют на API.

@karlosss "случайно, у вас есть публичный репозиторий" - извините, но нет, у меня нет ничего общедоступного в этой области, есть некоторые общедоступные, сделанные другими, но у многих из них та же проблема - они показывают очень кратко счастливый путь, который немного запутывает угловые случаи (но, с другой стороны, дает общее представление). Также вы можете просмотреть шаблоны ABP, которые имеют аналогичный подход AFAIK.

посмотрю, спасибо!