Hi, I'm implementing an API to create records for one type of object in batches. I have model called kpivalues but the standard rest rules mostly deal with acting on single records. So I've created an api where using kpivalues with post, update or delete will execute create, update or delete on a group of records defined in json as part of the body request. I know that is no restful, I checked around and that was pointed as a valid approach. I'm not obsessed with rest and anyway that is not the doubt I have, though might be related. In my controller api I receive the json and can iterate through the set of entries in the json and create, update or delete for each kpivalue. There are some checks to do before proceeding with the real action on the object and it is all in the controller which makes it a bit too crowded. I know I should move that to the model (or somewhere else), but those actions I do are auxiliary tasks like checking if the json parsing fails, or checking if some element in the json for an entry is valid to proceed, and so on. Where would that code belong? Should I anyway move it to the model and use it like Kpivalue::parseEntries for example? Should I use a module and use it from the controller (I'm not sure what difference would that make, I guess more testability but in the end it would be included in the controller anyway)? One doubt I have is about memory consumption if I pass a big string of json from the controller to the model, is that memory shared somehow what are the implications of passing big data between controller and models or modules (big string, say 5MB of data for example) Any good hints? Thanks.
on 2012-11-28 10:21
on 2012-11-28 17:03
Ha, I think this one was better on the ruby on rails space of the forum. Sorry for that. Any comments on this issue? I'm about to move the code I have in the controller to a separate module but since that will be included in the controller I'm not sure what are the benefits. Cheers.
on 2012-11-28 17:27
The basic RoR practice is to have 'thin' controllers. So the controller would, perhaps, validate / transform params then call something to do the work and then quit This sort of thing should be testable with unit tests. Which brings us back to thin controllers. If it results in a model or a class is not a major issue but being able to test things like this with unit tests as opposed to functional tests is. Also your first post is rambling on about something that has nothing to do with the real point of your post which is no one responded to you. Let me summarise what you really asked. Q: "I have a lot of code in my controller because that is where it is called. What are the benefits of moving this out into a sperate module / model / class?" A: "Ease of testing"
on 2012-11-28 17:37
Peter Hickman wrote in post #1086921: > Q: "I have a lot of code in my controller because that is where it is > called. What are the benefits of moving this out into a sperate module / > model / class?" > > A: "Ease of testing" Yeah Thanks Peter. Agree! Too much text on the original question. Sorry for that. I try to keep my controllers thin and its getting better everyday. Cheers.