Kohana与CodeIgniter有何不同?[已关闭]

我已经使用CodeIgniter很长一段时间了,但是最近我一直觉得需要迁移到更高级/更OOP的框架。Kohana似乎是一个经常被推荐的选择,我的问题是,Kohana与CodeIgniter究竟有什么不同?列出差异,特别是语法差异,会很棒。


答案 1

我将写关于Kohana 3.1以及到目前为止我看到的比CodeIgniter 2的主要优势。在Kohana 3.0(一年半以前)之前,我使用了CodeIgniter,ZF,Symfony,Cake,并尝试了许多其他方法(目前尝试做Yii只是因为我必须这样做)。我知道很多人会因为“主观”而向我吐口水。继续。

严格的 PHP 5.2

Kohana在当前版本中不使用任何旧代码(即2.x或CodeIgniter的代码)。它被完全重写为完全面向对象,而不是妨碍开发人员。简单地说,使用它进行开发感觉很自然,就像它是PHP开发的“方式”。

这是一个“由社区,为社区”建立的框架,而不是出于促销目的。不是由/为任何社区,而是一个非常鞣隄的社区。

CodeIgniter 在 PHP4 上静止了太久。看看CI2的源代码,我不能说他们已经完全迁移到PHP5(假设PHP 5.1不是真的......5菲律宾比索)。我看过FuelPHP,它似乎更像是CI2与Kohana的混搭,而不是CI2分支,尽管我不得不说它绝对有潜力。

断续器

Kohana感到自然的主要原因就是从这种模式中诞生的。我们的想法是隔离每个请求以尊重模式,最终尊重RFC 2616。现在,每个请求都有一个单独的 Response 对象,能够以非常整洁的方式重用代码。现在我正在开发一个与iPhone,Android和Web应用程序一起使用的网络服务。我无法描述“在内部”调用API是一种特权。原始示例:

public function action_delete()
{
    $deleted = Request::factory('api/route')
        ->method(Request::DELETE)
        ->headers('Accept', 'text/html')
        ->execute();

    $this->response->body($deleted);
}

无障碍

Kohana背后的团队致力于使框架“成为最好的”,而不是“它可以成为的一切,因为我们......有太多的空闲时间”。每个维护版本都与以前的版本向后兼容(例如,3.1.2与3.1.0),所有“主要”更改都等待次要版本(例如,3.1与3.0不完全向后兼容“开箱即用”)。以前的次要版本在新版本发布后将保留 6 个月。

引|声)

Kohana的级联文件系统使扩展现有组件甚至供应商使用的组件变得非常容易。您可以覆盖应用程序/模块级别上的所有内容,而无需考虑在任何地方手动设置包含/加载路径(因为所有文件和文件夹都遵循相同的约定)。

有一大堆模块,包括Zend框架。怎么样?简而言之,您甚至可以将采埃孚或任何其他库用作 Kohana 应用程序内的模块。

除了所有社区构建的模块外,每个Kohana安装都包括一些几乎每个应用程序都可以从中受益的模块:

  • 认证一个简单但功能非常强大的身份验证库。该模块本身仅提供文件身份验证驱动程序,但启用ORM为我们提供了更强大的驱动程序。

  • 缓存缓存库,其中包含最流行的缓存技术的驱动程序:APC,eAccelerator,file,memcache,SQLite,Wincache和Xcache。它非常容易实现和更改(即使以后对缓存驱动程序的更改也是单行的)。

  • 代码台如果你需要对一些代码进行基准测试,Codebench为你提供了一种非常简单的方法。

  • 数据库与Kohana中的其他所有内容一样,数据库模块也是完全面向对象和可扩展的。具有完整的MySQL和PDO支持。

  • 图像用于轻松图像操作的简单模块

  • 奥姆默认ORM基于ActiveRecord模式,充分利用数据库模块的优势,结合PHP 5的神奇方法。除此之外,您还可以使用Jelly,Sprig,AutoModeler或任何其他自定义PHP库,如Truction。

  • 单位测试Kohana预先打包了一个很棒的单元测试模块。它基于PHPUnit,并与您的应用程序完全“集成”,使您可以轻松地进行TDD。此外,整个框架都经过单元测试。

  • 用户指南尽管大多数开发人员忽略了这一点,但该模块是Kohanas最强大的功能之一。它提供了跟踪API和Kohana文档其余部分的最简单方法。为什么您的应用程序没有自己的指南呢?你甚至不必考虑它!只要您跟踪代码中的注释/约定,此模块将负责其余的工作。

代码示例

代码比CI的更整洁,所有类都是自动加载的,尽管约定非常相似。

更新示例(使用 ORM):

public function action_update($post_id)
{
    $post   = ORM::factory('post', $post_id);
    $errors = array();

    if ($values = $this->request->post())
    {
        try
        {
            $post->values($values)->update();

            $this->request->redirect('post');
        }
        catch (ORM_Validation_Exception $e)
        {
            $errors += $e->errors();
        }
    }

    $this->template->content = View::factory('post/update', array(
        'post'  => $post,
        'errors'=> $errors,
    ));
}

在此示例中,ORM 用于更新行,让 update() 调用它的 check() 方法来验证它的值。如果验证失败,ORM_Validation_Exception将被捕获,并且不会执行尝试块的其余部分(即重定向到 /post)。最后,post 对象 (Model_Post) 和 errors 数组都传递到 View,在那里可以直接访问它们。

请注意,所有Database_Query_Builder方法都在ORM内部可用,因此您也可以执行“花哨”操作,例如:

ORM::factory('post')
    ->where('user_id','=',$user_id)
    ->join('users','INNER')
    ->on('users.id','=','posts.user_id')
    ->find_all();

或(带关系):

$user = ORM::factory('user', $id);

foreach ($user->posts->find_all() as $post)
{
    foreach ($post->quotes->find_all() as $quote)
    {
        if ($quote->illegal())
        {
            $quote->delete();
        }
    }
}

其中 illegal() 可以是一些自定义模型级方法,其中包含花哨的联接和内容。我知道这个块看起来效率有多低,它只是一个代码示例,而不是“JOIN是否比其他查询更好”:)


推荐