It’s nothing really complicated; In its essence, it’s just a folder structure, but ASP.NET generators support the concept of aggregating controllers/ views and routes inside an “area” by default (Please don’t confuse this with Phoenix contexts, “areas” are meant as a web-app-only organization structure).
I’ve actually just been doing that today. I’m building a new project in both ASP.NET Core and Elixir/Phoenix to see what is a better fit.
I recreated the ASP.NET folder structure for “Areas” and and placed all controllers/channels/views/templates into there. If I remember correctly the biggest issue was that templates were not found by default so what I ended up doing was creating different macros for the controller/view for each area by duplicating the generated ones and changing the default namespace and template location.
I moved all of the default controllers/channels/views/templates into a “shared” area. This also required changing the default controller/view macros.
The Phoenix namespacing is pretty annoying to be honest as the controllers/views e.t.c. aren’t namespaced like most Elixir modules. Controllers and views have to live in the same namespace if you want them to work by convention, even though they’re in separate directories. Stick with “AppWeb.Areas.AreaName.ControllerName” and not “AppWeb.Areas.AreaName.Controllers.ControllerName”.
I decided to reverse my decision and go back to the default structure so everything was just subdirectories in the root controllers/views/templates directories. Mainly because I felt dirty for having a controller/view macro for each area and it’s easier using the generators.
I wrote about a similar idea awhile back. We found this structure helpful especially for server-rendered apps its easier to navigate if you keep templates with the controller and view. Its very easy to tweak the Phoenix generated macros to customize things the way you want to. And if you don’t have templates, you don’t have to tweak anything if you want to keep your view and controller together.
@sync08 So in other words, we would really have to go off the rails for this. In my experience, is always a bad idea to stray too much from a framework defaults if it is really opinionated regarding structure.
@jeremyjh I find that using the term “context” to describe this kind of folder structure in the web app to be misleading because we already use this word to represent application’s domain boundaries, and one thing does not lead to the other - necessarily. What you are presenting is similar to what I’ve used for years with ASP.NET, we call it “feature folders”, which is a vertical sliced folder structure.
I think it’s fine to customize your folder structure however you like and it’s not “going off the rails” as Elixir/Phoenix is flexible and doesn’t really care. You can co-locate your templates with your controller and view by making this tweak: Domain-oriented web folder structure with further discussion here: Discussion about domain-orientated folder structures in Phoenix