3 ms·
The talk is on YT and it’s easy to find by the title. I forgot to mention, whenever I see Ecto schema structs bubbling up to the views, I want to throw up.
by nesarkvechnep 4y ago
The talk is on YT and it’s easy to find by the title.
I forgot to mention, whenever I see Ecto schema structs bubbling up to the views, I want to throw up.
- agentwiggles 4y agoThis confuses me as a relatively green Phoenix dev. Wouldn't this be standard practice? As I've been reading through Programming Phoenix, this is done all over the place. For example, the "show" action for a "user" calls into the Users context to get a User struct, then passes that struct into the view for rendering. How else would you do it? It would seem to me (admittedly, naively) that anything else would introduce an unnecessary extra layer between the context and the view. What am I missing?
- nesarkvechnep 4y agoIt might be an unnecessary layer but sometimes it might not be. By having structs that you persist and structs that are “bound” to business logic functions you can have clean business logic and treat the persistence as a side effect, which it ultimately is. If your application is a simple CRUD app, then yes, bubbling up Ecto schema structs to the vies is sufficient.
- OkayPhysicist 4y agoI'm not positive I see your complaint. Ecto is supposed to be exactly the translation layer between your business logic and your storage layout. Adding another translation layer on top of that just results in a half-baked implementation of half of Ecto. If your Ecto structs aren't useful throughout your application, then maybe you need to do a little more translating in the schema itself.
- dns_snek 4y agoWould you mind expanding on why that is what you do differently?