7 ms·

I think the problem with MVC web frameworks in general is that it makes it makes the easy/boilerplate stuff really easy, but the hard stuff harder. Sure, if you

I think the problem with MVC web frameworks in general is that it makes it makes the easy/boilerplate stuff really easy, but the hard stuff harder. Sure, if you doing a simple CRUD app that is only updating a single table it is fine. Beyond that, you waste so much time trying to figure out how the frameworks wants you to represent composite objects, and debugging the default model binders, then thinking you might have to write your own binder, then just saying screw it and reverting to Request.Form[] and parsing your own requests.

generalk 16y ago
This is exactly the kind of response that concerns me. I'm looking for concrete Rails-specific issues. I understand that, in theory, Rails may suffer from this issue. In practice I've never once seen it. I think Request.Form is an ASP.NET thing. I have no experience there, so I can't comment on it.
joe_the_user 16y ago
I absolutely agree that a complex, n-table, n-page site does not scale with MVC in general. Simplistically, [n-tables] X [n-pages] = n^2 controller methods for n controllers. So trying to make the controllers nice and OO just means each controllers complexity expands excessively. I would be really curious. What pattern do people think scales in this general situation?
- generalk 16y ago
  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...

generalk 16y ago

This is exactly the kind of response that concerns me. I'm looking for concrete Rails-specific issues. I understand that, in theory, Rails may suffer from this issue. In practice I've never once seen it. I think Request.Form is an ASP.NET thing. I have no experience there, so I can't comment on it.

joe_the_user 16y ago

I absolutely agree that a complex, n-table, n-page site does not scale with MVC in general. Simplistically, [n-tables] X [n-pages] = n^2 controller methods for n controllers. So trying to make the controllers nice and OO just means each controllers complexity expands excessively. I would be really curious. What pattern do people think scales in this general situation?

generalk 16y ago
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...