我正在尝试使用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/
我想很多开发人员都会挂断电话，认为你需要自己的图层。在洋葱架构中，您通常会有一个“数据”层，通常称为DAL。当您使用像EF这样的ORM时，那就是您的数据层。换句话说，不是拥有一个单独的类库来创建数据库，EF就是那个库，因此，你就像使用自己的DAL库一样使用它，如果你有的话。
尽量不要挂在层和“干净”的架构上。事实上，最干净的架构是一个单一的项目。只有当事情开始变得笨拙时，才能打破“层”。换句话说，构建最简单的功能单元。如果涉及大量代码，你会发现自己重复代码，你有太多的依赖关系等等，然后开始在重构过程中破解东西。最终，你可能会得到所有花哨的层和100个不同的类库，或者其他什么，但尝试从那里开始是愚蠢的。如果您的应用实际上并不需要某些东西，添加它是愚蠢的。干净利落。
对于它的价值，这可能是TDD或测试驱动开发最无名的好处之一。您编写测试以确保您想要的某个特定事件发生，然后编写代码以满足该测试。重要的是，您只需编写代码来满足该测试。这自然意味着，你开始简单并转向复杂性。旧的红绿重构TDD方法的重构循环是清理代码，在必要时抽象事物，将逻辑移动到可重用库等的地方。即使你没有采用整个测试优先的编码方法，以这种方式看待开发仍然非常有益。你知道你需要构建什么，所以构建一个技术上满足这个要求的最简单的东西。然后重构。构建下一个需求，然后重新构建。让应用程序自然地成长为它实际需要的东西，而不是试图从一开始就断言某种架构，模式或进程。