I am not sure I agree with validation being on the web front. Checking length, uniqueness, inclusion of a value in a set are all part of your domain rules. However, I do think data casting should be done in the web layer and it is only done later for convenience.
And I do agree that relying on Ecto can lead to tighter coupling. On the other hand, we need a way to communicate rules between dependencies. Giving the before and after is not enough in case of errors, you need the error reasons, you need the attempted rules, and you need the attempted changes. You could use pure data structures but you would most likely need something more structured. Ecto.Changeset is one of those options. Even if you implement YourOwnChangesetLikeThing, you would need it to be available on both dependencies and you would get coupling there too.
I think the reason why Ecto is seen more like accidental coupling is because you can’t use just part of it, so the cause and consequence always goes like “my database has to use it and therefore I have to use it”. That’s why we are considering at least removing the ecto_sql and ecto_migrations part out of Ecto, so that it becomes more of a toolkit for data mapping and data change than a database library.
What do you think?
To be fair, the “phoenix is not your application” slogan is more about the fact that phoenix doesn’t run your applications, they are simply Elixir applications. i.e. “application” here means the runtime component. But that’s why I don’t like such slogans, it can be interpreted in multiple ways and the original intent is lost along the way.
