Refactoring bloated contexts

Phoenix Forum Questions / Help
,
1

Recently I’ve been working on an app using the Phoenix 1.3 structure. So far I really like contexts. I like how it forces me to think of the problem and I think it makes my code better. Also now my schemas and controllers are tiny, which I really like.

However, I did notice that the context files are starting to become a little bloated. I was wondering how people think about this problem. I like the idea presented in this post about separating queries into a separate module.

What other techniques would you suggest for splitting up context files or other ways to avoid bloated contexts.

1 Like
2

defdelegate is an option I’m considering for my fatter contexts at the moment. Haven’t given it much more thought that that yet though.

1 Like
3

defdelegate is a good idea, because it keeps the possibility for changes in the future open: “for now just delegate, but maybe in the future the internals change without the outside world having to know”.

4

Make submodules that refer to specific parts of you API, just like in every library:

Ecto.assoc/2
Ecto.Changeset.change/2

You can do with your context:

Accounts.list_users/0
Accounts.User.change/2
5

But in this case wouldn’t the Accounts.User module namespace already be taken by the User schema file?

6

I put all my schema’s inside the DB namespace in my ‘contexts’/sections. Makes it obvious what they are and keeps them out of the way (and encourages me not to access DB's in other sections ^.^).

1 Like