Reputation: 55
In Phoenix 1.3 is recommended to place all business logic into contexts, but one context can handle a lot of entities (I don`t know the correct word, since "model" is no longer exists in Phoenix 1.3) and it grows very quickly. What is the proper way to split context into several files?
EDIT
I have Account context and two entities: User and Credentials. Even with these 2 entities context looks a bit complex. I have to scroll over User's functions in order to reach the Credential's one. Right now it is not really a problem, but I suppose there can be more than 2 entities in one context and then it can be really massive. Or am I wrong?
This example is from phoenix's hexdocs.pm
Upvotes: 1
Views: 676
Reputation: 5812
It's very vital question, but actually it's totally up to you how you like to organize your code. Phoenix will not impact you any style, even contexts are just a suggestion to design with intent the code.
Right now your structure looks like following:
lib
> accounts
> accounts.ex
user.ex
credentials.ex
So either you can split the credentials
and users
into totally isolated contexts, which may not be best idea, as they are related with current Accounts
context or try to get benefit from introducing them as subcontexts. Propably you would fall into name clashing with users and credentials. Still it's doable.
credentials
might become a part of authentication
context, if you would like to design this way. There are several options for you how to tackle that.
Assuming that you would like to keep current structure, but introduce subcontexts, but at the very end, you still want to call them via main context, you can get use of defdelegate here.
The best advice is to consider what will happen next with your code and try to sort the things together in some logical way - credentials
are only for users, but they are one of the way to authorize users, so you can group them either have them as schema and subcontext for authorization or accounts context.
Upvotes: 3