Чистая архитектура ядра MVC без шаблона хранилища - PullRequest
0 голосов
/ 13 сентября 2018

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

1 Ответ

0 голосов
/ 13 сентября 2018

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...