bestie

Hi Tom

I have to disagree, by returning a value and switching on it, not only are you querying state but you risk repeating the query code all over the place.

My approach allows you to write a small adapter for your delivery mechanism and use polymorphism to eliminate conditions and duplication.

Most objects cannot be used on their own as they have collaborators. My design allows me to write a trivial console adapter that can puts the results of my service object / interactor.

I think this is a really good point, there is a huge difference between trivial data mapping and what an ORM does.

Wait while I make this edit ....

Route directly how? Write my own HTTP layer? It's so easy to take advantage of Rails' routing and view rendering.

It is no co-incidence :)

Ben Lane, the founder of The Audacious Art Experiment was one of my closest friends growing up, we were also in a band together.

Webby Rails types do often get very aggressive towards this kind of thinking. The point you made about this out-living Rails is a very good one. I'd be coding like this in any language with any framework, Ruby just makes writing SOLID code easy.

Unfortunately they have all been closed source thus far.

The problem with writing good code samples is that it requires a lot of time and thought. This was very much an MVP blog post and appears demand for the sample app / code snippets is very real so I will do my best to get something together.

Isn't more fun to spend all your time arguing on HN though? :)

+1 :)

I honestly can't think of any job I'd be happy leaving in the hands of a controller beyond the obvious HTTP routing and view rendering concerns.

Even adding a presenter, as I prefer, serializing your data should be handled by your service layer.

I'm not advocating writing an ORM, just some simple data translations from the raw database row data to a persistence-free domain object.

It is useful, the controller in this case handles web concerns and translates a HTTP message into a message that is meaningful to application.

So I'm not actually advocating writing an ORM just a data mapper. You map from one hash of data extracted form data base to something like a Struct. There's no SQL generation involved.

Having the indirection there allows you to take the Rails features you want with your boundary clearly defining which ones you depend on.

You could start with Rails, get ActiveRecord querying, migrations and template rendering for free and then maybe swap it out for Sinatra and the Sequel gem (I have actually done this).

Knowing your where your dependencies and technical debts are is very empowering.