_php instance analysis of business logic of CodeIgniter Controller

This paper analyzes the business logic of CodeIgniter controller. Share to everyone for your reference, as follows:

The previous analysis of the common controller distributed by the module, convenient for the control of specific modules, and the specific implementation of the class is placed in the library. Is it appropriate to put it in the library? And where are the more business logic in the controller?

First, the understanding of several folders in CI

Helpers, Libraries: Store a series of auxiliary functions, auxiliary classes, to assist the Controller, business logic implementation functions. Their approach should be as far as possible to avoid the reliance on CI, the tighter the more difficult to reuse. To send mail as an example, many parameters are constant when sending a message, such as encoding, protocol, port, etc., we may configure these parameters under Config, and then the library encapsulates a message sent by the class, and in which the CI instance is fetched after reading these parameters. At this point there is a dependency on the CI instance, the class can only be used in the CI framework, other systems to use, can only be rewritten, not to achieve the purpose of reuse. What if the sending class just receives parameters and encapsulates the sending method? So, as far as possible to make helpers, libraries change simple, responsibility becomes single.

Controllers: Controller directory. The controller is mainly used to take over the program and play the role of connection. Typically, we write the business logic in action. But as the business becomes more complex, the action code becomes bloated and difficult to maintain.

models: Model catalog. The main function of CI model is to deal with database and get data. The business logic is often put into the model, but the business logic and the model are actually two things. The model just gets the data, the business logic may be to combine the data according to the business needs, the composition may be many kinds, put in the model will make the model difficult to maintain and is not conducive to reuse. Say a hit example, to the data according to certain conditions to cache, get data and cache results two processes are written in the same method, but the same data need to do another form of caching when it is found that the method of acquiring data can not be reused.

Third_party: Third-party class library directory. Do not use directly after you get a class library, you can do a package in the library to make it more adaptable to the system, others will be less difficult to use.

Can be found that each folder has its own responsibilities, each module has its own home, has its own functions. What about the business logic?

In this case, we should also give business logic home, create a unique directory to store business logic, for the moment named service. The controller is mainly responsible for receiving parameters and calling Service,service to invoke the model, each layer does its duty.

Let's see how it's implemented:

We can rewrite the my_load and add the service method directly by copying the Code code as follows: $this->load->service (' User_service ');
But many business logic need to obtain CI instance, here can refer to the model method, the core establishes a my_service, the other service inherits the class, so the usage in the Sub service is the same as the controller.

Class my_service{public  function __construct ()  {    log_message (' Debug ', "Service Class Initialized");  }  function __get ($key)  {    $CI = & Get_instance ();    return $CI $key;  }}

In fact, the main idea is to have a layer to deal with business logic, Java has this layer. With the constant familiarity with CI, it is found that this layer needs to be achieved in order to liberate the controller and model. And this similar practice, if there are many places in the system need to use the Web service or the cache and so on, in fact, can be in accordance with the above ideas alone in a folder to handle, easy to manage.

More interested in CodeIgniter related content readers can view this site topic: "CodeIgniter Introductory Tutorial" and "CI (codeigniter) Framework Advanced Tutorial"

It is hoped that this article is helpful to the PHP program design based on CodeIgniter framework.

