Чистая архитектура Net Core MVC без шаблона репозитория

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

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

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