+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Using CodeIgniter (https://forum.codeigniter.com/forumdisplay.php?fid=5)
+--- Forum: Best Practices (https://forum.codeigniter.com/forumdisplay.php?fid=12)
+--- Thread: 1 controller = 1 model VS. 1 controller = multiple model (/showthread.php?tid=71499)
Pages:
1
2
RE: 1 controller = 1 model VS. 1 controller = multiple model - luiszagaceta - 08-27-2018
Ideally, you should use a model for a table and invoke according to what you are going to use
RE: 1 controller = 1 model VS. 1 controller = multiple model - bhaumikkothari - 08-27-2018
Yes keeping 1controller - 1 model will be ideally helpful.
Though there are few exceptions sometimes that is why we create models against specific set of feature.
For e.g Login_model will have everything related to:
- Check user
- Forgot password
- Session creation
- Logout
Also thinking from controller perspective for e.g. Checkout controller on any ecommerce site can deal with multiple models such as:
- Customer_model
- Order_model
- Invoice_model
RE: 1 controller = 1 model VS. 1 controller = multiple model - kaitenz - 08-27-2018
Another question.
What if I load a model to a specific controller but that model is dependent to the other model?
Should I load also the "other model"?
RE: 1 controller = 1 model VS. 1 controller = multiple model - Pertti - 08-28-2018
(08-27-2018, 01:20 PM)skunkbad Wrote: I do this for authentication, because the tables are all related, and most don't need their own model.
Ah, like moving hashes to separate table, away from your normal firstname, lastname, etc table?
I have been pondering for some time if I should implement that on our stuff, because really, hashes are only used once, during login, and kinda bloat user table for any other case.
Glad to see someone else thinks it's a good idea too.
RE: 1 controller = 1 model VS. 1 controller = multiple model - Pertti - 08-28-2018
(08-27-2018, 11:12 PM)kaitenz Wrote: What if I load a model to a specific controller but that model is dependent to the other model?
Should I load also the "other model"?
You have quite few options here, and depending on your coding principles, one might sound better than other.
1. Autoload all your models, all the time. I can't help but think this could be massive waste of resources having to load in additional PHP script files, but for some small apps, this could be acceptable solution.
2. You could load other model in parent models __construct() method. This way whenever parent model is created, it's certain that necessary other models are available too. I'd imagine there might be some cases where trying to load model every time new instance of parent model is created could also affect performance.
3. You load child model code only in methods that require use of that model.
4. You load child models on controller level. Probably the most likely way to break your code if you accidentally forget to load model for specific action, and forget to test it.
5. Use dependency injection. This is probably the hardest concept to understand, but the cleanest / transparent way to code, plus as by-product, the code should be easier to unit test. It does involve loading models in controllers, but instead of letting models handle all the stuff behind the scenes, you load data on controller level, then pass instances between models, instead of IDs.
RE: 1 controller = 1 model VS. 1 controller = multiple model - bhaumikkothari - 08-28-2018
(08-27-2018, 11:12 PM)kaitenz Wrote: Another question.
What if I load a model to a specific controller but that model is dependent to the other model?
Should I load also the "other model"?
Model methods are meant to be reused from multiple controllers as and when required.
We just need to load that model in the controller function before using its method.
For e.g. a code snippet to print invoice will use couple of models
PHP Code:
function printinvoiceMulti($invoiceid){
$this->load->model('log_in');
$userrights=$this->log_in->check_user_type();
$data['userrights']=$userrights;
$this->load->model('program_model');
$data['unitdetail']=$this->program_model->checkunitcode();
$this->load->model('invoice_model');
$data['all_reservation']=$this->invoice_model->all_reservation_for_invoiceprint($invoiceid);
$data['alltaxgroup_items']=$this->invoice_model->get_taxgroup_items($invoiceid);
$data['allreservationaddons']=$this->invoice_model->all_reservation_addons($invoiceid);
$count = count($data['all_reservation']);
if($data['all_reservation']!=null){
$this->load->view('invoice/print_invoice_multi_res',$data);
}else{
redirect(base_url());
}
}
RE: 1 controller = 1 model VS. 1 controller = multiple model - albertleao - 08-28-2018
(08-27-2018, 05:11 PM)skunkbad Wrote: So then how do you handle joins?
Mostly in libraries.
In my workflow, if the join is pulling in child data, I use a function within the parent model. For example, if you have 1 blog post with 10 tags, I'd have a function called 'tags()' in my BlogPost model that I could call to get related data.
I do have some models with join statements but I try to keep them as clean as possible. Keeping separation can make a huge difference down the road if your app gets big.
RE: 1 controller = 1 model VS. 1 controller = multiple model - skunkbad - 08-30-2018
(08-28-2018, 09:25 PM)albertleao Wrote:(08-27-2018, 05:11 PM)skunkbad Wrote: So then how do you handle joins?
Mostly in libraries.
In my workflow, if the join is pulling in child data, I use a function within the parent model. For example, if you have 1 blog post with 10 tags, I'd have a function called 'tags()' in my BlogPost model that I could call to get related data.
I do have some models with join statements but I try to keep them as clean as possible. Keeping separation can make a huge difference down the road if your app gets big.
To illustrate what you would do, how about something like this:
Code:
SELECT *
FROM A
LEFT JOIN B
ON A.id = B.a_id
WHERE A.foo = "bar"RE: 1 controller = 1 model VS. 1 controller = multiple model - albertleao - 09-04-2018
(08-30-2018, 11:41 AM)skunkbad Wrote:(08-28-2018, 09:25 PM)albertleao Wrote:(08-27-2018, 05:11 PM)skunkbad Wrote: So then how do you handle joins?
Mostly in libraries.
In my workflow, if the join is pulling in child data, I use a function within the parent model. For example, if you have 1 blog post with 10 tags, I'd have a function called 'tags()' in my BlogPost model that I could call to get related data.
I do have some models with join statements but I try to keep them as clean as possible. Keeping separation can make a huge difference down the road if your app gets big.
To illustrate what you would do, how about something like this:
Code:SELECT *
FROM A
LEFT JOIN B
ON A.id = B.a_id
WHERE A.foo = "bar"
I'm aware of how joins work, I'm just saying that most of mine are in libraries.
RE: 1 controller = 1 model VS. 1 controller = multiple model - mfox - 09-10-2018
I think it really depends on the project. In general, I usually have a 1:1 setup like others have said, but not always. For example, in a reporting section, I have one controller (Reports) but it uses several different models (orders, clients, suppliers, etc.). As others have said, models represent people or things ("entities") your app tracks (in my case it's orders, clients etc.), even if they work with more than one database table.
But in your case, it sounds like you're doing this, but keeping it a bit too general. A "forms" model could potentially handle everything an app does! If your model is getting too big and confusing, maybe break it down further. That happened to me awhile back, where I had 2 different types of clients with 2 very different types of orders. In that case, having a single "orders" model would have gotten unnecessarily huge and complicated, so each type of order had its own model. The "bottom line" is that you should do whatever works best in your situation, as long as you maintain a good separation of concerns.
HTH
