Is it okay/advisable to use input methods directly in models?

[eluser]robnecciai[/eluser]
New to CI. I'm building a rather large site and, while I'm laying the groundwork, I have discovered that there are many posts on this forum that show example of using input->post methods directly within data models. Is this "best practices"?

example (in a data model):

function insert()
{
$data = array('userName' => $this->input->post('username'), 'age' => $this->input->post('age'));
$this->db->insert('member', $data);
}

If this is okay, can I also assume that it would be ok to traverse the input->post() array and "dynamically" build the data array to pass to the db->insert function?

I'm just looking for a good, solid, and fairly generic pattern for performing these actions.

[eluser]SPeed_FANat1c[/eluser]
I am new to CI too, but have little experience already with it and I think it is better use function parameters.
When you use this->input->post then you can use the function for very specific task. When you use parameters, you can use the same function for severals tasks.

My 2 cents.

[eluser]robnecciai[/eluser]
[quote author="SPeed_FANat1c" date="1287525816"]I am new to CI too, but have little experience already with it and I think it is better use function parameters.
When you use this->input->post then you can use the function for very specific task. When you use parameters, you can use the same function for severals tasks.

My 2 cents.[/quote]

I tend to agree. In fact, that's the way I've coded my models so far. I was just checking to make sure I wasn't missing something more obvious.

Thanks.

[eluser]techgnome[/eluser]
I'd say it's a matter of debate. How ever, it's my preference as well to get the values from the post in the controller and pass them in an array (that way if you add/remove items, you don't need to change parameters to match) or through parameters. In MVC in its purest form, the model doesn't care where its inputs come from, it just receives input from the controller. Meanwhile, the view shouldn't care where its data came from either. The controller sits in the middle acting as traffic control.

That said, in the end, it doesn't matter, depending on how much you care about maintaining the level of separation between the different layers.

On the other hand, if you remove or add an element to the form being POSTed, you'll surely be making changes to your model (to either stop storing it, or start storing it)... which means also a change to the controller (since it will either exist or not as part of the post data) ... resulting three changes. The argument could be made that by getting the POST data in the model, you reduce your changes to the form and the model and the controller doesn't care.

Meh.

-tg

[eluser]Watermark Studios[/eluser]
Encapsulation 101 - The model should only be self-aware. It should not depend on exterior environmental factors. What happens if you want to use the same model to handle a user insert from a file upload? Or from a Facebook plugin? I'm working on an application right now that integrates with PayPal's PayFlow Pro Gateway with recurring billing. I am using the same User model for admin control of accounts as I am with my PayPal integration controller.

Best practice is to keep $_POST out of the model. Let the model be as generic as you can make it and let the business logic handle the $_POST-to-property assignment. It's the same effort up front to do so, but it makes the User model more portable. I re-use my User model in almost every application. I make changes here and there, but because of encapsulation, I don't have to think about how my application needs to be molded around my model.

Best of luck!

Ken