我正在尝试使用eshoponweb示例应用程序在Net Core 2.1中创建MVC应用程序。我已经读过，在实体框架核心中，放入存储库层并直接使用ef dbcontext没有太大好处。我将如何在干净的建筑场景中做到这一点。在示例应用程序中，dB上下文位于基础结构层中，而业务服务逻辑全部位于应用程序核心中。我曾考虑过将其中任何一个都搬走，但那不会阻止干净的架构想要实现的分离。 https://github.com/dotnet-architecture/eShopOnWeb和https://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework-core/
答案 0 :(得分：4)
我认为许多开发人员被困的原因是您需要自己的图层。在洋葱体系结构中，通常会有一个“数据”层，通常称为DAL。当您使用像EF这样的ORM时，这就是您的数据层。换句话说，EF不是创建要与数据库一起使用的单独的类库，而是该库，因此，如果有的话，就可以像使用自己的DAL库那样使用它。
尽量不要挂在层和“干净”的体系结构上。实际上，最干净的体系结构是一个项目。只有当事情开始变得笨拙时，才有可能打破“层次”。换句话说，构建您可以使用的最简单的功能单元。如果涉及一堆代码，您会发现自己在重复代码，依赖关系过多等，然后在重构过程中开始进行分解。最终，您可能会遇到所有花哨的层和100个不同的类库，或者其他任何东西，但是尝试在那里 start 是愚蠢的。如果您的应用实际上不需要什么，添加它是愚蠢的。简单明了。
就其价值而言，这可能是TDD或测试驱动开发中最鲜为人知的好处之一。您编写测试以确保发生某件事，然后编写代码来满足该测试。重要的是，您只需 编写代码即可满足该测试要求。这意味着自然而然地，您从简单开始，然后走向复杂。旧的红绿重构TDD方法的重构周期是您清理代码，在必要时进行抽象，将逻辑移入可重用的库等。即使您没有执行整个测试优先的编码方法，以这种方式看待开发仍然非常有益。您知道您需要构建什么，因此构建最简单的技术上可以满足该要求的东西。然后重构。建立下一个需求，然后再次进行重构。让您的应用程序自然地成长为实际需要的东西，而不是尝试从一开始就断言某种架构，模式或过程。