Consider this to be a pummeling massage of a not quite living equine. If using one of the several JSON de-serialization (view) methods available in Rails (JBuilder, AMS, etc.), the suggested way to write the JSON service part of a Rails application would be:
1. Define the schema through the migrations. 2. Define the models and their associations to match the relationships in the schema. 3. Define the controller that has queries (using the model, which uses the defined schema). 4. Define the AMS, JBuilder, or whichever view that again defines the associations to determine what JSON to render. 5. Go back into the controller and have to add the necessary code (hash) to the query to eager load associations after the development of the view has been stabilized somewhat. In many cases (not all), there is unnecessary replication of what data you want from the DB, eager loaded, to provide to the client. At worst people are actually making those n+1 as separate HTTP(S) requests through different controllers and lock themselves into a design that keeps them from being easily able to eager load. This is not Roy's vision of hypermedia-driven REST. A single resource can be composed of data from multiple table. It is just convention in Rails to have a single controller to a single model and a single model to a single table. I understand separation of concerns, but there seems to be some emerging duplication that could go away now that jbuilder views are being generated in the scaffold generator and time is being put into AMS. Just want to make it better. Thanks! -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
