如果一个项目中分了两块，如前台、后台，那这个功能是否为前后台都必须？ 如果前后台还有不同的业务模块区分， 是否是每个模块都要用到？

如果都需要， 那写在这里就很好， 如果不需要， 就不建议写在这里。

对于相关的类库、函数调用应该按需加载

实现加载的方式有很多，可以在指定的页面load， 可以在公用的控制器、函数里面load， 一经load即可全局使用。个人的常用做法是忽略该文件，手动加载全局函数等。

说到这里，顺便说下CI的加载机制。下面为类库、函数等的加载方式：

$this->load->library(''session'');
$this->load->model(''hello_model'');
$this->load->helper(array(''url'', ''array''));
$this->load->language(array(''user_menu'', ''user_tips''));

加载方式统一，使用起来比较简单，但load类库时传参有点不方便。再次load类库时不会再去加载，而是从保存好的静态数组中拿出来，需要注意下成员属性的状态，防止因为值还存在而导致程序异常。

更多关于CodeIgniter相关内容感兴趣的读者可查看本站专题：《codeigniter入门教程》和《CI(CodeIgniter)框架进阶教程》

希望本文所述对大家基于CodeIgniter框架的PHP程序设计有所帮助。

Codeigniter composer 和 __autoload魔术方法冲突解决

废话不多说了，直接看源代码把

CI首先加载的是system/core/Codeigniter.php 阅读发现(165行)：

if ($composer_autoload = config_item(''composer_autoload''))
	{
		if ($composer_autoload === TRUE)
		{
			file_exists(APPPATH.''vendor/autoload.php'')
				? require_once(APPPATH.''vendor/autoload.php'')
				: log_message(''error'', ''$config[\''composer_autoload\''] is set to TRUE but ''.APPPATH.''vendor/autoload.php was not found.'');
		}
		elseif (file_exists($composer_autoload))
		{
			require_once($composer_autoload);
		}
		else
		{
			log_message(''error'', ''Could not find the specified $config[\''composer_autoload\''] path: ''.$composer_autoload);
		}
	}

果然CI3根目录下的composer.josn不是拿来开玩笑的。 在配置文件里，我们同样可以看到是否开启composer。

/*
|--------------------------------------------------------------------------
| Composer auto-loading
|--------------------------------------------------------------------------
|
| Enabling this setting will tell CodeIgniter to look for a Composer
| package auto-loader script in application/vendor/autoload.php.
|
|	$config[''composer_autoload''] = TRUE;
|
| Or if you have your vendor/ directory located somewhere else, you
| can opt to set a specific path as well:
|
|	$config[''composer_autoload''] = ''/path/to/vendor/autoload.php'';
|
| For more information about Composer, please visit http://getcomposer.org/
|
| Note: This will NOT disable or override the CodeIgniter-specific
|	autoloading (application/config/autoload.php)
*/

那么很明显，CI3已经完全可以支持COMPOSER了。 为试验里一下，在composer.json里加入里阿里支付的接口 然后

composer update;

在相应的控制器里加入代码

use mytharcher\sdk\alipay;
  function test1(){
        $this->pay_config = $this->config->item(''alipay'');
        $alipay = new \mytharcher\sdk\alipay\Alipay($this->pay_config);
        var_dump($alipay);
    }

果然打印出ali支付类的信息了。 但是发生里什么情况呢？ 为了让我的视图和逻辑分开，我特别写了一个MY_View_Controller用于无逻辑的页面的加载 测试的时候，报错了。

Message: Class ''MY_View_Controller'' not found

Filename: controllers/Welcome.php

找不到类？ 经调试，关闭掉composer，就不会发生这个错误了。 为了解决这个错误，那么再次读源码把 既然是composer与autoload冲突，那么为只管看composer的代码就好了

代码加载顺序  vendor/autoload.php  =>  vendor/composer/autoload_real.php  => vendor/composer/Classloader.php

终于，在Classloader类中（298行），发现了loadclass($class)方法
好像和 __autoload($class)方法很像?

   public function loadClass($class)
    {
        if ($file = $this->findFile($class)) {
            includeFile($file);

            return true;
        }
    } 

那么我们在方法内部加上

  /**
         * 增加核心库依赖加载
         */
        if(strpos($class, ''MY_'') === 0)
        {
            if (file_exists(APPPATH . ''core/''. $class . EXT)) {
                @include_once( APPPATH . ''core/''. $class . EXT );
            }

        }

果然好用了。

但是冲突的原因依旧没找到，肠炎犯了，下次再研究。 当然，为了让项目的其他人使用composer同样可以兼容这个错误，我们只需要再.gitignore文件中加入即可

vendor/
!vendor/autoload.php
!vendor/composer/*

CodeIgniter 如何解决URL含有中文字符串 codeigniter thinkphp codeigniter 3.0 codeigniter session

CodeIgniter自定义控制器MY_Controller用法分析，codeigniter控制器

codeigniter自定义控制器my_controller用法分析，codeigniter控制器

本文实例讲述了codeigniter自定义控制器my_controller用法。分享给大家供大家参考，具体如下：

Codeigniter所有的控制器都必须继承CI_Controller类，但CI_Controller类位于system目录下，不太方便修改。为方便做一些公用的处理，通常情况下我们会在core下创建MY_Controller，用来继承CI_Controller，从而项目中所有的控制器继承MY_Controller。

那么，MY_Controller 通常会做些什么呢？

所有的控制器都继承了MY_Controller， MY_Controller常常会加载一些公用帮助函数、公用类库，以及实现一些公用的方法。

公用的方法？公有的方法？

看到这些方法会意识到一个问题，如果方法是public的，那是否可以通过浏览器访问到。答案是可以的！这样不该让用户访问到的方法让用户访问到了。那设置protected吧。。。

备注:CI_Controller中写public方法不会被访问到，框架限制了CI_Controller中方法通过浏览器访问。

随着项目的不断进展，MY_Controller中的公用方法会越来越多。如果此时要增加后台管理的功能，所有的控制器依然继承MY_Controller，那其中的很多方法可能不适用了。如果后台需要的一些公用方法也写在这里，这里将会变得混乱。

如何按模块区分不同的控制器？

有两种处理的方式，第一种是通过不同的公用控制器文件来区分，由控制器去决定继承哪一个公用控制器，当然这里得引入公用文件。还有这种方式是可以通过对象的一个属性来维护，不同的模块赋予该属性不同的对象。如：

<&#63;php 
if ( ! defined(''BASEPATH''))
  exit(''No direct script access allowed'');
class MY_Controller extends CI_Controller
{
 public function __construct($type = NULL)
 {
   parent::__construct();
   switch($type) {
    case ''api'' :
     $this->load->library(''api_helper'', NULL, ''helper'');
     break;
    case ''admin'' :
     $this->load->library(''admin_helper'', NULL, ''helper'');
      break;
    default :
     $this->load->library(''app_helper'', NULL, ''helper'');
      break
   }
 }
}
/* End of file MY_Controller.php */
/* Location: ./application/core/MY_Controller.php */

控制器调用MY_Controller构造函数并传入type值，根据不同的type值会加载不同的类库，然后给类定义一个统一的别名，方便处理。具体的library可以处理该模块公用的方法或load公用的资源，相当于该模块的一个公用类。当然处理方式也可以是直接通过路由中的目录名或者控制器名称来控制等等。

这样避免了加载不同的文件，调用方法时只需要通过$this->helper对象调用。在仔细看看，可以发现不同模块的公用类是放在library中，放在library或helper中都可以使用get_intance获取控制器对象，但每次使用都需要获取实例，相对麻烦，如果是模型呢？感觉也不太好。其中的公用方法有一些会跟业务逻辑相关，放在library感觉不太合适。

业务逻辑好像并没有一个好的地方去实现，控制器的私有方法？模型？

先总结下上面的处理方法：

1、不同模块之间可以按需加载以及实现自定义的公用方法，各个模块之间互不影响。如果各模块之间的公用方法比较多，也可以再去继承一个公用的类。

2、公用方法放在library中，调用CI实例不方便。

3、如果不喜欢$this->herlper的调用方法，可以让控制器去继承不同的公用控制器，思路是一样的，只是可能需要手动引入文件。

更多关于CodeIgniter相关内容感兴趣的读者可查看本站专题：《codeigniter入门教程》和《CI(CodeIgniter)框架进阶教程》

希望本文所述对大家基于CodeIgniter框架的PHP程序设计有所帮助。

您可能感兴趣的文章:

• Codeigniter控制器controller继承问题实例分析
• 2个Codeigniter文件批量上传控制器写法例子
• CodeIgniter钩子用法实例详解
• CodeIgniter配置之database.php用法实例分析
• CodeIgniter多语言实现方法详解
• CI(CodeIgniter)模型用法实例分析
• CodeIgniter视图使用注意事项
• CodeIgniter读写分离实现方法详解
• CI(CodeIgniter)简单统计访问人数实现方法
• CodeIgniter控制器之业务逻辑实例分析

CodeIgniter自定义控制器MY_Controller用法分析，codeigniter控制器_PHP教程

codeigniter自定义控制器my_controller用法分析，codeigniter控制器

本文实例讲述了codeigniter自定义控制器my_controller用法。分享给大家供大家参考，具体如下：

Codeigniter所有的控制器都必须继承CI_Controller类，但CI_Controller类位于system目录下，不太方便修改。为方便做一些公用的处理，通常情况下我们会在core下创建MY_Controller，用来继承CI_Controller，从而项目中所有的控制器继承MY_Controller。

那么，MY_Controller 通常会做些什么呢？

所有的控制器都继承了MY_Controller， MY_Controller常常会加载一些公用帮助函数、公用类库，以及实现一些公用的方法。

公用的方法？公有的方法？

立即学习“PHP免费学习笔记（深入）”；

看到这些方法会意识到一个问题，如果方法是public的，那是否可以通过浏览器访问到。答案是可以的！这样不该让用户访问到的方法让用户访问到了。那设置protected吧。。。

备注:CI_Controller中写public方法不会被访问到，框架限制了CI_Controller中方法通过浏览器访问。

随着项目的不断进展，MY_Controller中的公用方法会越来越多。如果此时要增加后台管理的功能，所有的控制器依然继承MY_Controller，那其中的很多方法可能不适用了。如果后台需要的一些公用方法也写在这里，这里将会变得混乱。

如何按模块区分不同的控制器？

有两种处理的方式，第一种是通过不同的公用控制器文件来区分，由控制器去决定继承哪一个公用控制器，当然这里得引入公用文件。还有这种方式是可以通过对象的一个属性来维护，不同的模块赋予该属性不同的对象。如：

<&#63;php 
if ( ! defined(''BASEPATH''))
  exit(''No direct script access allowed'');
class MY_Controller extends CI_Controller
{
 public function __construct($type = NULL)
 {
   parent::__construct();
   switch($type) {
    case ''api'' :
     $this->load->library(''api_helper'', NULL, ''helper'');
     break;
    case ''admin'' :
     $this->load->library(''admin_helper'', NULL, ''helper'');
      break;
    default :
     $this->load->library(''app_helper'', NULL, ''helper'');
      break
   }
 }
}
/* End of file MY_Controller.php */
/* Location: ./application/core/MY_Controller.php */

控制器调用MY_Controller构造函数并传入type值，根据不同的type值会加载不同的类库，然后给类定义一个统一的别名，方便处理。具体的library可以处理该模块公用的方法或load公用的资源，相当于该模块的一个公用类。当然处理方式也可以是直接通过路由中的目录名或者控制器名称来控制等等。

这样避免了加载不同的文件，调用方法时只需要通过$this->helper对象调用。在仔细看看，可以发现不同模块的公用类是放在library中，放在library或helper中都可以使用get_intance获取控制器对象，但每次使用都需要获取实例，相对麻烦，如果是模型呢？感觉也不太好。其中的公用方法有一些会跟业务逻辑相关，放在library感觉不太合适。

业务逻辑好像并没有一个好的地方去实现，控制器的私有方法？模型？

先总结下上面的处理方法：

1、不同模块之间可以按需加载以及实现自定义的公用方法，各个模块之间互不影响。如果各模块之间的公用方法比较多，也可以再去继承一个公用的类。

2、公用方法放在library中，调用CI实例不方便。

3、如果不喜欢$this->herlper的调用方法，可以让控制器去继承不同的公用控制器，思路是一样的，只是可能需要手动引入文件。

更多关于CodeIgniter相关内容感兴趣的读者可查看本站专题：《codeigniter入门教程》和《CI(CodeIgniter)框架进阶教程》

希望本文所述对大家基于CodeIgniter框架的PHP程序设计有所帮助。

您可能感兴趣的文章:

• Codeigniter控制器controller继承问题实例分析
• 2个Codeigniter文件批量上传控制器写法例子
• CodeIgniter钩子用法实例详解
• CodeIgniter配置之database.php用法实例分析
• CodeIgniter多语言实现方法详解
• CI(CodeIgniter)模型用法实例分析
• CodeIgniter视图使用注意事项
• CodeIgniter读写分离实现方法详解
• CI(CodeIgniter)简单统计访问人数实现方法
• CodeIgniter控制器之业务逻辑实例分析

关于CodeIgniter配置之autoload.php自动加载用法分析和自动加载 php的介绍现已完结，谢谢您的耐心阅读，如果想了解更多关于Codeigniter composer 和 __autoload魔术方法冲突解决、CodeIgniter 如何解决URL含有中文字符串 codeigniter thinkphp codeigniter 3.0 codeigniter session、CodeIgniter自定义控制器MY_Controller用法分析，codeigniter控制器、CodeIgniter自定义控制器MY_Controller用法分析，codeigniter控制器_PHP教程的相关知识，请在本站寻找。