如何构建用作Web API的.NET Azure Function App？函数类文件组织疑问

两种方案的优劣势对比 #

1. 同一类文件存放所有CRUD函数 #

这种方式适合小型测试项目或者快速原型开发：

• 好处：
  • 上手快，不用折腾多个文件，初期维护起来省事
  • 可以共享类级别的依赖（比如注入的数据库上下文），少写重复代码
• 问题：
  • 随着API功能变多，这个类会越来越臃肿，几百上千行代码后，找个特定端点的逻辑得翻半天
  • 多人协作时，很容易出现文件合并冲突，毕竟大家都在改同一个文件
  • 不符合单一职责原则，一个类扛了所有CRUD的逻辑，时间长了代码可读性和可维护性都会下降

2. 每个端点（或相关端点组）单独一个类文件 #

这种方式更适合中大型项目或者需要长期维护的API：

• 好处：
  • 符合单一职责原则，每个类只管一件事（比如CreateProductFunction专门处理创建请求，GetProductFunction专门处理查询请求），职责清晰
  • 每个类文件都很小，找特定逻辑的时候直接找对应文件就行，效率高
  • 多人协作时冲突概率低，各自负责对应的文件就行
  • 后续扩展方便，新增端点直接加个类文件，不会打乱原有代码结构
• 注意：
  • 如果有共享依赖，只要配置好Azure Functions的依赖注入就行，不用担心重复注入的问题
  • 还可以按业务模块分组，比如把所有产品相关的CRUD函数放在Products文件夹下，结构更规整

总结建议 #

• 要是你只是做个小测试或者快速搭个原型，把所有CRUD函数放同一个类里完全没问题，省时间
• 但如果是需要长期维护、功能还会不断加的API，强烈建议每个函数（或者逻辑相关的一组函数）单独一个类文件，这会让代码结构更清爽，后续维护和协作都省心

内容的提问来源于stack exchange，提问作者iqoOopi