Business logic example analysis of CodeIgniter controller, codeigniter controller_PHP tutorial

Analysis of business logic examples of CodeIgniter controller, codeigniter controller

This article analyzes the business logic of CodeIgniter controller with examples. Share it with everyone for your reference, the details are as follows:

As analyzed earlier, public controllers are distributed by modules to facilitate the control of specific modules, and the specific implementation classes are placed in the library. Is it appropriate to put it in the library? And where should more business logic be placed in the controller?

First let’s talk about the understanding of several folders in CI

helpers, libraries: Stores a series of auxiliary functions and auxiliary classes to assist controllers and business logic to implement functions. The methods among them should try to avoid dependencies on CI. The tighter the dependencies are, the more difficult they are to reuse. Take email sending as an example. Many parameters remain unchanged when sending emails, such as encoding, protocol, port, etc. We may configure these parameters under config, and then the library encapsulates an email sending class and obtains a CI instance in it. Then read these parameters. At this time, there is a dependency on the CI instance. This class can only be used in the CI framework. If it is used in other systems, it can only be rewritten, which does not achieve the purpose of reuse. What if the sending class only receives parameters and encapsulates the sending method? Therefore, make helpers and libraries as simple as possible and have a single responsibility.

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

models: Model directory. The main responsibility of the CI model is to deal with the database and obtain data. Many times, business logic is also placed in the model, but business logic and model are actually two different things. The model only obtains data, and the business logic may be to combine the data according to business needs. There may be many combination methods. Putting it in the model will make the model difficult to maintain and not conducive to reuse. Let’s talk about an example I encountered. Data is cached according to certain conditions. The two processes of obtaining data and caching results are written in the same method. However, when the same data needs to be cached in another form, it is found that the method of obtaining data is There is no way to reuse it.

third_party: Third-party library directory. After getting a class library, don't use it directly. You can encapsulate it in the library to make it more suitable for the system, and it will be less difficult for others to use it.

You can find that each folder has its own responsibilities, each module has its own home and its own functions. What should we do with the business logic?

In this case, we should also give the business logic a home and create a unique directory to store the business logic, temporarily named service. The controller is mainly responsible for receiving parameters and calling service, and service calls the model. Each layer performs its own duties.

Let’s see how to achieve it:

We can rewrite MY_Load, add the service method, and call it directly through copy the code The code is as follows: $this->load->service('user_service'); .
However, many business logics require obtaining CI instances. Here you can refer to the model method, core creates a MY_Service, and other services inherit this class, so that the usage in the sub-service is the same as in 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 handle business logic, and this layer is available in Java. As I continue to become familiar with CI, I find that this layer is needed here to achieve the purpose of liberating the controller and model. There are many similar approaches to this. If there are many places in the system that need to use web services or cache, you can actually follow the above idea and put them in a separate folder for easy management.

Readers who are interested in more CodeIgniter related content can check out the special topics on this site: "codeigniter introductory tutorial" and "CI (CodeIgniter) framework advanced tutorial"

I hope this article will be helpful to everyone’s PHP program design based on the CodeIgniter framework.

Articles you may be interested in:

• CodeIgniter custom controller MY_Controller usage analysis
• Codeigniter controller controller inheritance problem example analysis
• 2 Codeigniter Example of writing batch file upload controller
• Detailed explanation of CodeIgniter hook usage example
• CodeIgniter configuration database.php usage example analysis
• Detailed explanation of CodeIgniter multi-language implementation method
• CI (CodeIgniter) model usage example analysis
• Notes on using CodeIgniter view
• Detailed explanation of the codeIgniter read-write separation implementation method
• CI (CodeIgniter) simple statistics of the number of visitors implementation method

http://www.bkjia.com/PHPjc/1094760.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/1094760.htmlTechArticleCodeIgniter controller business logic example analysis, codeigniter controller This article analyzes the business logic of CodeIgniter controller through examples. Share it with everyone for your reference, the details are as follows: Previous...