我正在尝试使用 eshoponweb 示例应用程序在 net core 2.1 中创建一个 MVC 应用程序。我读到，在 Entity Framework 核心中，放入存储库层并直接使用 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 个不同的类库，或者其他什么，但尝试从那里开始是愚蠢的。如果您的应用程序实际上不需要某些东西，那么添加它是愚蠢的。简单明了。
就其值(value)而言，这可能是 TDD(即测试驱动开发)最不为人所知的好处之一。您编写一个测试来确保发生您想要的一件特定事情，然后编写代码来满足该测试。重要的是，您仅编写代码来满足该测试。这自然意味着，你会从简单开始，逐渐变得复杂。旧的红绿重构 TDD 方法的重构周期是清理代码、在必要时抽象事物、将逻辑移至可重用库等的地方。即使您没有采用整个测试优先的编码方法，以这种方式看待开发仍然非常有益。您知道需要构建什么，因此构建在技术上满足该要求的最简单的东西。然后重构。构建下一个需求，然后再次重构。让您的应用程序自然地成长为它实际需要的样子，而不是试图从一开始就断言某种架构、模式或流程。
关于asp.net-core - Net core MVC 整洁的架构，没有存储库模式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52318032/