Hacker News Reader

Comment by stevewilhelm | Hacker News Reader

We have been moving the complex logic out of the models into libraries. But we are not happy with this approach.

We also find it difficult to cleanly develop views where data is needed from several different models. The whole Rails REST and MVC model gets in the way.

Would love to hear about how other wiser people have deal with these situations.

View on HN

The last time I was on a project where we found ourselves facing that problem, we solved it by going to a Javascript-based thick client (aka, a Single Page App). The server's responsibility was to do nothing but supply a JSON API to the thick client written in Javascript.

It solved the problem nicely -- in fact, so much so that it uncovers the fact that there's a flaw in the concept of using MVC to build a server-driven web app. (Not an insurmountable flaw, obviously, because we've all done it for years. Maybe I should call it an "awkwardness" or something like an "impedance mismatch").

I think what you are in need is nothing to do with model separation. But, you need to be careful about which code belongs to your business logic. For the views you mentioned, I don't know your code but I think you may use something interim, like a presenter code which takes data from the models and helps views to show it.

> something interim, like a presenter code which takes data from the models and helps views to show it

..something like a "controller"? :P

so use presenters... easy.

I think a great way to deal with this is to have services/actions that return the appropriate hashes. Pass the hashes into your views and let them do what they're going to do with them. You won't have biz logic creeping into a view that way because views are dealing with dumb hashes, not real entity objects.

Reply on news.ycombinator.com