Welcome Guest, Not a member yet? Register   Sign In
where do "actions" go?
#1

I'm still quite new to programming but have been using PHP\CodeIgniter for a year or two.

I've been keeping my controllers really clean recently by putting all my data retrieve options in models, just loading and retrieving data in my controllers via the models and then passing this to views.

Now I also have script for example that pings some IP's and reports on the status, at the moment I have this "action" in a model, feeding the result back into a DB, then another model/method that pulls the results to parts of the application that need that information. I thought this was the cleanest way.

Yesterday I came across an article/discussion where people pointed out some code as "wrong" as the user was performing "actions" in a model rather than just retrieving data, which apparently is all models should do.

So my question is, to keep my code clean but adhering to best practice, where is the best location to keep my actions? Some actions can be 50-100 lines easy, so I don't want them clogging up my controllers.

I know there isn't a perfect answer as everyone does things different, I was just wondering how many years experience you have and what it is that you do?

Thanks R
Reply
#2

I would put them in a library. You can read about libraries here:

http://www.codeigniter.com/user_guide/ge...aries.html

They are very powerful tool in CI.

Best wishes,

Paul.
Reply
#3

Traditionally, the methods in controllers are referred to as actions, but, since we're calling controller methods based on the URL, and we might want an "action" to be available from multiple locations (and there are all sorts of issues with calling multiple controllers given the way CI treats the controller), a library is a good alternative.

However, if the "action" is really just something which is rooted in your business logic, there are very good arguments for keeping it in your model, or dividing your model into two models (the one with the business logic which you would load directly and the one with the lower-level database interaction which would be loaded by your business-logic-model).

When looking at most design patterns which define a model, the model is a much higher-level object than what we typically have in CodeIgniter. Part of this is simply because most design patterns come from other languages which often supply higher-level interfaces to the database as part of their standard libraries. So, the idea of building a model which performs basic CRUD operations exists, but isn't really widely used in those languages.

Further, no matter where you ultimately put the code, you don't want your business logic for a particular operation repeated or spread across multiple classes. So, in my opinion, you can create a library or a model to hold this code, but it just makes more sense to me, from the perspective of the controller, to load a model when I need to do something which ultimately results in a change to the database, than to load a library. I'm perfectly fine with the idea of separating business logic and CRUD, and having them both exist in models (or the business logic in a library and the CRUD in a model), but I would take great lengths to avoid (or even prevent) loading the CRUD model directly from the controller if this is the case.
Reply
#4

(09-16-2015, 07:49 AM)mwhitney Wrote: Traditionally, the methods in controllers are referred to as actions, but, since we're calling controller methods based on the URL, and we might want an "action" to be available from multiple locations (and there are all sorts of issues with calling multiple controllers given the way CI treats the controller), a library is a good alternative.

However, if the "action" is really just something which is rooted in your business logic, there are very good arguments for keeping it in your model, or dividing your model into two models (the one with the business logic which you would load directly and the one with the lower-level database interaction which would be loaded by your business-logic-model).

When looking at most design patterns which define a model, the model is a much higher-level object than what we typically have in CodeIgniter. Part of this is simply because most design patterns come from other languages which often supply higher-level interfaces to the database as part of their standard libraries. So, the idea of building a model which performs basic CRUD operations exists, but isn't really widely used in those languages.

Further, no matter where you ultimately put the code, you don't want your business logic for a particular operation repeated or spread across multiple classes. So, in my opinion, you can create a library or a model to hold this code, but it just makes more sense to me, from the perspective of the controller, to load a model when I need to do something which ultimately results in a change to the database, than to load a library. I'm perfectly fine with the idea of separating business logic and CRUD, and having them both exist in models (or the business logic in a library and the CRUD in a model), but I would take great lengths to avoid (or even prevent) loading the CRUD model directly from the controller if this is the case.

Thanks both for your responses. Thanks mwhitney for a very detailed response explaining your thought process, very helpful.

Thanks again
R
Reply
#5

(This post was last modified: 09-16-2015, 02:41 PM by cartalot.)

for me the difference between a model and a library -- do i need to pick up and drop the functionality into another application? 
then it should be a library because it forces you to make it somewhat self contained. 
OR is this something which is mostly third party code? then make a library out of it because that will make it easier to upgrade later.

then there is the difference between fat controllers and thin controllers. it sounds like you are doing thin controllers which is my preference. as i build and refactor i push everything possible to a model - form data validation, database interaction, business logic.

so then typically the controller tells a model to verify or return data -- and either the data comes back or it doesn't.
when you need to change the data structure or some business rule - that happens in the model, so the controller does not have to change.

i'm also starting to use models for preprocessing data for a view when necessary - this keeps the views as 'dumb' and simple as possible. Otherwise you end up chasing down business logic changes in the controller, models, and views. If you can contain where things change then it makes it easier to maintain.
Reply
#6

(09-16-2015, 02:40 PM)cartalot Wrote: for me the difference between a model and a library -- do i need to pick up and drop the functionality into another application? 
then it should be a library because it forces you to make it somewhat self contained. 
OR is this something which is mostly third party code? then make a library out of it because that will make it easier to upgrade later.

then there is the difference between fat controllers and thin controllers. it sounds like you are doing thin controllers which is my preference. as i build and refactor i push everything possible to a model - form data validation, database interaction, business logic.

so then typically the controller tells a model to verify or return data -- and either the data comes back or it doesn't.
when you need to change the data structure or some business rule - that happens in the model, so the controller does not have to change.

i'm also starting to use models for preprocessing data for a view when necessary - this keeps the views as 'dumb' and simple as possible. Otherwise you end up chasing down business logic changes in the controller, models, and views. If you can contain where things change then it makes it easier to maintain.

I agree with everything you've said there thanks. 

It's nice to have thin simple controllers that control the flow and have the models doing the grunt. Like you, I also branch out into libraries if I'm going to use that functionality elsewhere. Thanks for the feedback.

I know there isn't much love for CI in the open world but the projects I work can always be completed with CI keeping it light and streamlined.

Thanks community!
Reply
#7

If you really want to clean your controller then you have to used all three (model, helper and libraray) ion proper way also you can use some plugin and It will be better if you will Follow the codeigniter rule
Reply
#8

Interesting discussion !

After using CI a bit (and having created a rather large Java/Spring app before), I ended thinking too, that it will be better to have business logic in my models, with 2 levels models, one level for DB CRUD and one level for business logic.
I was curious to think if it was a "correct" way of doing things ... or if I was going insane: glad to read I can still think clearly ! Wink

Thanks for all the wisdom shared !
Reply
#9

I use my_ model so most of the database interaction is coverd there. I put business logic in model. For better separation you can create two model one for data access and one for business logic put them in sub folder in models directory.
          Heart  love codeigniter Heart
          Learning  best  practices
     Rate my post if you found it helpfull
Reply




Theme © iAndrew 2016 - Forum software by © MyBB