
Hanami v0.9.0 Released - ksec
http://hanamirb.org/blog/2016/11/15/announcing-hanami-090.html
======
rvdavis
I'm glad that there are alternatives to Rails still being developed. I have
looked at both projects independently before, and it makes sense for Hanami to
adopt ROM as it's ORM.

------
dakull
from the guides:

>Hanami components are decoupled each other. This level of separation allows
you to use the ORM (data layer) of your choice. [0]

So indeed, one could use a preferred ORM. Yes the ORM looks a bit verbose and
the part with the relations being experimental is a show stopper.

Ignoring all that, Hanami is quite nice architecturally speaking [1] it could
evolve into the Phoenix of the Ruby ecosystem.

[0] - [http://hanamirb.org/guides/models/use-your-own-
orm](http://hanamirb.org/guides/models/use-your-own-orm)

[1] - [https://github.com/hanami/hanami](https://github.com/hanami/hanami)

------
ksec
Finally gotten on the front page and a few comment.

It seems the Ruby communities aren't interested in anything but Rails.
Especially in US and Japan. I have only seen Hanami mentioned in EU
conference.

------
ioquatix
Is it just me, or does this seem like a solution looking for a problem?
Especially the verbose way the ORM works... just seems overly complex without
actually solving any real problem I had with ActiveRecord.

~~~
riffraff
separation of the entities and repositories is useful in many ways.

For example, you can stub the repository and avoid persisting objects in
tests, and only test persistence in the appropriate ones.

Or, you always know that operations you call on an entity won't touch the
database, so you avoid a whole class of problems (think: accidental N+1
queries in a loop).

Or, by making the query interface private to the repository, you avoid
accidental leakage of storage details (think: `default_scope` impacting
associations)

I believe Ecto/Phoenix adopts a similar pattern
[http://www.phoenixframework.org/docs/models](http://www.phoenixframework.org/docs/models)

------
aikah
tldc; an Ruby ORM for PostgreSQL for those who don't want to click.

~~~
scottmf
It's actually an entire web framework. RoR for the "modern web".

~~~
eropple
More interestingly, there's a big crossover with dry-rb, which is some of the
stuff that makes me think that Ruby (my preferred glue/new-Perl language by a
country mile) can actually sanely scale to large projects with large teams.
(My experiences with dynamically-typed languages mostly are a shitshow past a
certain point, but dry-types and dry-struct are, at least, the starting point
of _something_ that's a little less kooky.)

Right now I've been using hanami-validations, which incorporates a bunch of
dry-rb, in completely non-web projects and it's _great_. Functional, typed
conversions are really comfortable and easy with dry-rb; my main beef is a
lack of a good way to dump data back out into an interchange format (like, I'd
like my types to be able to JSONify themselves), but that's relatively minor.

