Hacker News Reader

Comment by rapnie | Hacker News Reader

Jenny Shih did a conference talk about how Phoenix Contexts fit into Clean Architecture project organization. The slide deck is here (sample code is on Github): https://speakerdeck.com/jennyshih/context-driven-development...

View on HN

The relevant Github repo https://github.com/jenny-codes/elixirlab

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.

I'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.

This 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?

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

Would you mind expanding on why that is what you do differently?

Reply on news.ycombinator.com