4 ms·

In the simple case, Rails likes you to have seven controller methods and one controller per table. Realistically I usually end up throwing a few more methods on

In the simple case, Rails likes you to have seven controller methods and one controller per table. Realistically I usually end up throwing a few more methods on each controller. This is actually part of the reason I like Rails: it guides the developer towards what I consider to be better application design. I understand that a lot of folks don't agree, and that's cool for them, but I still like hearing why.

angrycoder 16y ago
I can see that working if each of the 7 tables was their own individual entity, but I am talking about a composite object here. Normalized data. How do you manage a transaction across 7 different controller methods? I am not saying their isn't a nice way to do this, merely using this as an example of why people may not like Rails. It forces you to figure out the Rails way of doing things. And that may not always be the best way for you, especially if you are an experienced developer.
- johnbender 16y ago
  You're describing a problem that arises as a consequence of using an ORM, any ORM, which is not at all Rails specific.
  - angrycoder 16y ago
    when you have to spread your updates across 7 different controller actions (methods) to make it work the Rails way, it most certainly is a rails problem.
    - vowelboy 16y ago
      You're assuming that there is a hard coupling between Controllers and Models. There isn't. Rails suggests a CRUD pattern, but doesn't enforce it. You can quite easily (and elegantly) update 14 different tables from one form, using one request and one controller method.
      - generalk 16y ago
        You can quite easily (and elegantly) update 14 different tables from one form, using one request and one controller method. You can very transparently do it with ActiveRecord associations, so that you're operating on only one instance of a model, or you can do it very opaquely, where you instantiate and update several models. Or you can just run an UPDATE statement; those haven't gone away.
joe_the_user 16y ago
I agree Rails work pretty well when you've an "average" app that doesn't spread across a lot of tables. The problems only when things go past averageness in one way or another. I actually have had more problems with Rails in personal apps I wanted to develop than in apps for clients. Rails is a paradox - the bleeding edge framework that works for only non-bleeding-edge sites...

angrycoder 16y ago

I can see that working if each of the 7 tables was their own individual entity, but I am talking about a composite object here. Normalized data. How do you manage a transaction across 7 different controller methods? I am not saying their isn't a nice way to do this, merely using this as an example of why people may not like Rails. It forces you to figure out the Rails way of doing things. And that may not always be the best way for you, especially if you are an experienced developer.

johnbender 16y ago
You're describing a problem that arises as a consequence of using an ORM, any ORM, which is not at all Rails specific.
- angrycoder 16y ago
  when you have to spread your updates across 7 different controller actions (methods) to make it work the Rails way, it most certainly is a rails problem.
  - vowelboy 16y ago
    You're assuming that there is a hard coupling between Controllers and Models. There isn't. Rails suggests a CRUD pattern, but doesn't enforce it. You can quite easily (and elegantly) update 14 different tables from one form, using one request and one controller method.
    - generalk 16y ago
      You can quite easily (and elegantly) update 14 different tables from one form, using one request and one controller method. You can very transparently do it with ActiveRecord associations, so that you're operating on only one instance of a model, or you can do it very opaquely, where you instantiate and update several models. Or you can just run an UPDATE statement; those haven't gone away.

joe_the_user 16y ago

I agree Rails work pretty well when you've an "average" app that doesn't spread across a lot of tables. The problems only when things go past averageness in one way or another. I actually have had more problems with Rails in personal apps I wanted to develop than in apps for clients. Rails is a paradox - the bleeding edge framework that works for only non-bleeding-edge sites...