Refactoring bloated contexts

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

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

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”.

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


You can do with your context:


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

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