Hi to all! 
As I’m finishing my small lighting talk for the upcoming local Ruby meetup that will cover Sinatra, Roda, and Hanami, I encountered Erica’s Ruby off Rails talk where she presented this graph about Hanami structure:
So, I’m wondering what you think about it. Is it correct? I believe Entities are Structs, right? I like it and would like to use it, and maybe even enhance it.
I have watched almost all available recorded talks about Hanami by Luca, and Tim – BTW, the Livin’ la Vida Hanami talk is crazy awesome, and I absolutely like how you create a local unique context for ALL of your talks! I will now go through the all Hanami docs.
Regarding docs, the search is not working as it should, at least for “slices” keyword:
FWIW, I’m a Ruby newbie with a web/tech support background and a little bit of PHP/Laravel knowledge. So far, I really like what you have achieved with the Hanami!
Cheers from Croatia! 
…
Iskren
I think if someone really needs to reason about Hanami in MVC terms, it’s more or less correct. What’s missing here is that actions = controllers. And I would probably put relations and DB out of “model” box.
But to be honest, is there really a definition of “web MVC” we could refer to?
Thanks for the answer. Well, actually Erica compared MVC as it is implemented inside the Rails, that was her reference point.
So, I don’t think Rails have formal definition too. We are only left with something like a “reference implementation”. And we can go all philosophical about this.
Take “model”, for example. If we think about the model as something that has the business logic (and represents some domain thing, as in “domain modelling”) - in Hanami that would be entity. It holds data and behaviours. Repositories and relation form persistence layer - an important, but technical layer of writing the state into the database. From the theoretical point of view, the business could be working with out it. From the practical, of course, no web app can get away without it.
In Rails model mixes these two responsibilities into one class. This makes defining it very difficult and sometimes it just “not a controller, no a view”. With the advent of Hotwire, it’s not even uncommon to see controller’s or view’s responsibilities put into a Rails’ model (yes, I’ve seen rendering partials in models; i18n is another example).
Another thing is views. “Views” in Rails are basically templates. Next to them we have helpers - bags of stateless functions to DRY out views. But there is really no concept of view, unless you use ViewComponent, Cells or Phlex.
In other frameworks view is a place to put the code that is only relevant to showing the things to the user. It does not affect the business processes, only the display. The parts are useful extension here - decorators specific to entities, adding display-only things to them (for example, taking “gender”, “first name” and “last name” from User producting "Mrs. Jane Smith" string.
This is my view of things. So as much as some things are easily mapped into Rails concepts, others are not. And some simple Rails concepts are divided into multiple ones in Hanami, to provide better separation (and testability).
I’ll kind self-repeat myself from my post about connected stuff but I see it as Hanami implementing a far more detailed MVC than for example Rails. In classic rails MVC maps 1 to 1. M is just rails models, V is rails view (partials) and C is controllers. Hanami delves into that pattern more deeply and expands on each of the “letters” with more detailed solutions, So View is not just a template/partial, its HanamiViews, which has multiple layers, Controller splits up into more atomic actions, and Model is a whole different world with repositories, structs etc.
There are multiple comparisons to be made between Hanami and Rails (like @katafrakt mentioned, actions are basically controllers, but split into multiple files). To me Hanami still implements MVC, but in a drastically different way than other frameworks I’ve seen (Elixir Phoenix being the closest one I guess)
