Чистая архитектура net core mvc без шаблона репозитория

Я пытаюсь создать приложение MVC в net core 2.1, используя пример приложения eshoponweb. Я читал, что в ядре Entity Framework нет большого преимущества от добавления уровня репозитория и прямого использования ef dbcontext. Как бы я сделал это в сценарии чистой архитектуры. В примере приложения контекст дБ находится на уровне инфраструктуры, а логика бизнес-сервисов - в ядре приложения. Я думал о перемещении любого из них, но тогда это не помешает разделению, которого стремится достичь чистая архитектура. https://github.com/dotnet-architecture/eShopOnWeb и https://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework-core/

Нет большого преимущества использовать репозиторий (или единицу работы) с EF, потому что он уже реализован (но без соглашений об именах). DbContext - это единица работы, а DbSet <T> - это общий репозиторий.

Brad 14.09.2018 01:40

Я согласен со всем, что Крис Пратт сказал ниже. Лично я считаю, что пример проекта eShopOnWeb действительно перегружен и плох для обучения. Он создает интерфейс для каждого отдельного класса и связывает каждый отдельный класс как службу, а затем фактически не использовать какой-либо из инъекций зависимостей в своих тестах. Большинство его сервисов тривиальны и могли быть простыми ванильными классами, инстанцируемыми напрямую, или статическими служебными методами, или чем-то еще.

Joe Irby 21.12.2018 05:35
5
2
2 632
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Я думаю, что многие разработчики зацикливаются на том, что вам нужны собственные слои. В луковичной архитектуре у вас обычно есть уровень «данных», обычно называемый DAL. Когда вы используете ORM, например EF, это ваш уровень данных. Другими словами, вместо отдельной библиотеки классов, которую вы создаете для работы с базой данных, EF является этой библиотекой, и поэтому вы бы использовали ее так же, как и свою собственную библиотеку DAL, если бы она у вас была.

Постарайтесь не зацикливаться на слоях и «чистой» архитектуре. По правде говоря, архитектура самый чистый - это единый проект. Только когда это становится громоздким, имеет смысл разбивать «слои». Другими словами, создайте простейшую единицу функциональности, какую только сможете. Если задействована куча кода, вы обнаруживаете, что повторяете код, у вас слишком много зависимостей и т. д., А затем начинаете ломать вещи как часть процесса рефакторинга. В конце концов, вы можете получить все причудливые слои и 100 различных библиотек классов или что-то еще, но глупо пытаться там использовать Начните. Если вашему приложению что-то действительно не нужно, глупо это добавлять. Легко и просто.

Как бы то ни было, это, вероятно, одно из самых незамеченных преимуществ TDD или разработки, основанной на тестировании. Вы пишете тест, чтобы убедиться, что происходит что-то конкретное, что вы хотите, а затем вы пишете код, удовлетворяющий этому тесту. Важно отметить, что вы Только пишете код, удовлетворяющий этому тесту. Это означает, что, естественно, вы начинаете с простого и переходите к сложности. Цикл рефакторинга старого подхода TDD с красно-зеленым рефакторингом - это когда вы очищаете код, абстрагируете вещи там, где это необходимо, переносите логику в повторно используемые библиотеки и тому подобное. Даже если вы не применяете весь подход к кодированию, основанный на тестировании, все равно очень полезно смотреть на разработку таким образом. Вы знаете, что вам нужно построить, поэтому создайте наиболее простую вещь, технически удовлетворяющую этому требованию. Затем проведите рефакторинг. Создайте следующее требование и снова выполните рефакторинг. Позвольте вашему приложению естественным образом вырасти до того, чем оно на самом деле является потребности, вместо того, чтобы пытаться утверждать какую-то архитектуру, шаблон или процесс с самого начала.

Это отличный совет.

serpent5 13.09.2018 21:15

Приветствую вас за ваш вклад. Возьму на борт.

JimmyShoe 13.09.2018 22:01

На данный момент это самая большая проблема в моей компании ... они думают, что мы исправим один способ, и около 70+ будут следовать ему вечно, что совершенно неверно ... они отказываются понимать, что оптимизация кода продолжается ... вы продолжите рефакторинг кода после того, как разработаете его ... для моей компании, как только вы напишете код, он будет готов ... вы больше не будете его трогать

Dhaval 04.06.2020 12:32

Любая компания с такой философией обречена на провал или, по крайней мере, неуместна. Вещи меняются, и особенно в программном обеспечении в наши дни, изменения происходят часто с головокружительной скоростью. Ваш код должен постоянно развиваться, или вы просто накапливаете технический долг, и проценты по нему в конечном итоге вас потонут.

Chris Pratt 04.06.2020 13:38

Другие вопросы по теме