我最近适应的拇指规则是这样的:
图书馆
图书馆必须尽可能独立。在许多情况下,您甚至可能不会使用get_instance()
,因为该库应该在其内部处理大多数事情。
将库视为解决问题的通用解决方案,就像 CodeIgniter 自己的库一样,它们中的大多数/全部都是独立的并具有特定目的。
你读Form_validation
了,这正是它的作用。您不需要其他库或模型来工作。$config
一个好的库是每个人都可以通过简单地更改值来将其用于自己的应用程序的库。
图书馆应该能够在session
图书馆等情况下使用数据库查询;通过使用在配置文件中设置的表名。
模型
模型应尽可能与数据库查询相关,但更重要的是,为您的项目制作模型。这就是库和模型的不同之处。我曾经偶然发现的典型问题是这样的;如果我的模型只应该处理数据库调用,我应该将我的项目特定的非数据库函数放在哪里?它们不应该在库中,将它们放在助手中没有意义,那么我应该把它们放在哪里呢?
我的解决方案是使用通用模型。虽然我所有的其他模型文件_model
都general
以application/models/general
. 如果我运行$this->general->load('utester')
,我可以通过$this->general->utester
.
现在,这可能会受到质疑等,但这是我在 CodeIgniter 工作 3 年后得出的结论;一个基本上可以让你做任何你想做的事情的框架。在里面$this->general
,我知道逻辑与数据库查询没有直接关系。它的功能可以是为 a 组装数组form_dropdown()
,它可以是我的登录行为的模型,也可以不是。
帮手
帮助程序最适合解析内部视图文件。尽管您可以使用$this
内部视图,但最鼓励在将变量发送到视图之前在服务器端尽可能多地处理,剩下的应该使用辅助函数进行解析。如果一个函数在视图和控制器中都被大量使用,你不妨把它当作一个助手。
助手永远不需要使用数据库查询。
我已经为这个冲突制定了自己的解决方案,我希望至少能启发你一点,让你想出自己的解决方案。不要试图在 CodeIgniter 中找到“最佳”解决方案,选择最有意义的解决方案,而不会对它产生不良感觉。在我看来,CodeIgniter 意味着找到自己的个人解决方案的自由。
我不介意听听你对我的方法的意见。有些人可能认为它不正确,但让批评者成为你的意见,仅此而已。
1) 我的自定义应用程序/models/general.php的代码
<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');
/* Used for Model scalability */
class General extends CI_Model {
var $loaded = array();
function load($mix)
{
$arr_load = array();
$boo_is_array = is_array($mix);
$boo_return_class = ! $boo_is_array;
if ($boo_is_array)
$arr_load = $mix;
else
$arr_load[] = $mix;
foreach ($arr_load as $int_key => $str_class) {
$str_lower = strtolower($str_class);
$str_name = ucfirst($str_class);
$str_file = APPPATH . "models/general/{$str_lower}.php";
$boo_success = FALSE;
if (file_exists($str_file))
if ( ! in_array($str_lower, $this->loaded)) {
require_once $str_file;
$this->$str_lower = new $str_name();
$boo_success = TRUE;
}
if ( ! $boo_success)
unset($arr_load[$int_key]);
}
if ($boo_return_class)
return $this->$str_lower;
return (bool) count($arr_load);
}
}