Forum: Ruby Using model methods without an object for that model

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.

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.

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"

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.