Do you organize/separate your Ecto Schemas?

Phoenix Forum Chat / Discussions
,
1

Hi guys,

I’ve been working on a few Phoenix applications by now, and something I keep changing is the way I organize my Schemas, because somehow, I’m never satisfied.

At the beggining, my schemas were in my context folder (lib/app/account/user.ex) however as soon as my context gets bigger, my schemas slowly fades out among the other files. I think it hard for a teammate to know which file is a schema and which is not.
After this, I tried to group all my schemas in a separate folder (lib/app/schemas/user.ex) and while I like the idea, I still had this problem that sometimes, a schema and a context file have the same name. I have to use alias x, as: xSchemas in some files, so overall, it’s confusing because of the naming changes from one file to another.

Anyway, today I need to setup a new project and here I am, having a subfolder schemas in my context folder and also adding the suffix ‘Schema’ to all my schemas to avoid name shadowing (lib/app/account/schemas/user_schema.ex). But I am also considering using plural for schemas only and keeping them in my schemas folder.

At this point I guess you understood that I am very picky with readability and organization. I think Elixir and Phoenix are amazing for this but this one thing keeps me up at night.

Curious to know if any of you already found the ultimate answer, I haven’t found anything on this forum nor Github !

Cheers,

2

How about using plural for the context? So you’d have:

lib
  - accounts
    - account.ex
    - user.ex
  - accounts.ex
4 Likes
3

I usually always start with lib/<app>/schema/ and only move to smaller and more contained directories as the app starts to grow.

2 Likes
4

I don’t think there is an ultimate answer, but I tend to start out simple and expand as needed.

For example, I might start out with…

lib
  - inventory
    - property.ex - schema
  - inventory.ex - context

You’re just talking about schemas here, but as more concepts get added, eventually the high-level including schemas might be…

lib
  - inventory
    - properties.ex - sub-context with property crud and such
    - property.ex - schema
    - units.ex - sub-context with unit crud and such
    - unit.ex - schema
  - inventory.ex - context that delegates to functions in `properties.ex` and `units.ex`

Some apps will even break out a separate context/app that is only concerned with data persistence and then interact with that from the other business domain contexts. In those cases, I’d tend to break into /lib/<app>/schema, /lib/<app>/queries, etc. since it is a pure data layer.

I’ve done the analysis paralysis thing when it comes to this topic and it rarely seems worth it though. There is a decent chance that whatever organization that makes sense today might need to evolve in the future. I think that is okay. Elixir tends to make renames and restructuring fairly painless.

2 Likes
5

I’ve used this on several large phoenix projects and it’s always worked well. It’s easy browse the directory structure and also easy to find the right file when fuzzy searching in an editor.

2 Likes