c# - dotnet core api 文件夹结构

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭12 个月前。

Improve this question

我正在尝试启动一个新的 API。但有很多选项可以被认为是正确的。我只是想知道每个人都建议如何这样做，或者是否有一种我忽略的官方方法。这将是一个 N 层架构。具有 Controller /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

I just wonder how everyone suggest doing it, or if there's an official way to do it that I'm ignoring

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

至于“官方”指南 - 您可以查看 Common web application architectures来自微软的指南。它提到了几个流行的选项:

• Traditional "N-Layer" architecture applications
• Clean architecture (我认为这与六边形架构和洋葱架构非常相似，它们或多或少基于相同的概念，但在术语和细微差别上有所不同)

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

还有一个值得一提的是Vertical Slice Architecture ( video presentation )据我了解，这与我个人在过去几年中越来越喜欢的功能文件夹方法非常相似(请参阅 this 、 this 和 this )