Programmers know the benefit of everything and the tradeoffs of nothing.
Phoenix gives you a range of choices and the different choices are about different sets of tradeoffs - so it is ultimately up to the developer to choose the tradeoffs that are most beneficial to the situation at hand.
- “Phoenix is your application” is easy to learn and a fast initial development style; i.e. has a short time-to-initial-success but tends to sacrifice maintainability.
- “Phoenix contexts” and “umbrella projects” attempt to improve maintainability at the cost of slowing you down with refactoring to maintain the appropriate level of separation and boundaries which tend to introduce a a bit more code and possibly complexity required for the improved decoupling.
- Bare path dependencies maximize decoupling (if done correctly) but also introduces more overhead.
why wouldn’t you still be able to use
Ecto.Changesetfor data validation?
Because the idea behind Ecto hiding behind Todo.Database is to not let the fact that Ecto is being used leak out - otherwise what is the point in encapsulating it, it is supposed to be an implementation detail.
That being said there are plans to move the SQL and migration functionality into separate packages so that core Ecto is about data, not databases. However even having a canonical data schema throughout the entire system can lead to problems with unnecessary coupling.
