dotnet core api 文件夹结构

Question

我正在尝试启动一个新的 API。但有很多选项可以被认为是正确的。我只是想知道每个人都建议如何这样做，或者是否有一种我忽略的官方方法。这将是一个 N 层架构。具有控制器/BLL 类/DAL 层。以及一些与消息队列和其他服务进行通信的服务（我在同一解决方案中提取到不同的项目），但我的问题是对于主项目，你们将如何处理文件夹/命名空间。以及其中类的命名。这就是我愿意采取的方式，让我知道我们的想法：

apiproject
|
+> controllers/
|  + *Controller.cs (name of classes)
+> enumerables/
|  + *.cs (just a significant name)
+> handlers/
|  + I*Handler.cs (interfaces)
|  + implementors/
|  |  + *Handler.cs (implementations)
 +  Models/
|  +  *.cs (meaningfulName)
 +  DTO/
|  +  *.cs (meaningfulName)
 +  Validators/
|  +  *Validator.cs (DataAnnotations)
 +  Utils/
|  +  *Util.cs 
 +  Repositories/
|  +  I*Repository.cs 
|  + implementors/
|  |  + *Repository.cs (implementations)
|  + Entities/
|  |  *Entity.cs
+  Auth/
|  + MiddleWareStuff

我主要在命名约定上遇到困难，例如处理程序可以吗？你们如何组织中间件和动作过滤器？

提前致谢 ！

Answer 1

我只是想知道每个人都建议如何这样做，或者是否有一种我忽略的官方方法

没有一种方法是正确的，只有适合您、您的团队和您的项目的方法。

至于“官方”指南 - 您可以查看Microsoft 的通用 Web 应用程序架构指南。它提到了几个流行的选项：

• 传统“N层”架构应用
• 干净的架构（我认为它与六边形架构和洋葱架构非常相似，它们或多或少基于相同的概念，但在术语和细微差别上有所不同）

您可以阅读有关这些内容的多种资源。

另外值得一提的是垂直切片架构（视频演示），据我了解，它与功能文件夹方法非常相似，我个人在过去几年中越来越喜欢这种方法（参见这个，这个和这个）