I'm trying to start a new API, but there are a bunch of options that can be considered correct. I just wonder how everyone suggest doing it, or if there's an official way to do it that I'm ignoring.
This is going to be a N Layer architecture. With controllers / BLL classes / DAL layer. and some services to communicate with message queues and other services (which I'm extracting to different projects in the same solution) but my question would be for the main project how would you do the folders/namespaces and naming of the classes in it. This is how I'm willing to approach, let me know your thoughts:
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
I struggle mainly with the naming conventions, for instance is handler ok? How do you organize your middlewares and action filters?
I just wonder how everyone suggest doing it, or if there's an official way to do it that I'm ignoring
There is no one right approach, there are ones that can work for you, your team and your project.
As for "official" guides - you can look into Common web application architectures guide from Microsoft. It mentions several popular options:
There are multiple resources on those you can read about those.
One more which is worth mentioning is Vertical Slice Architecture (video presentation) which as far as I understand is quite similar to Feature Folders approach which personally I've grown fond over the last years (see this, this and this).