srcmini本文概述
在过去的一个月中, CakePHP团队宣布推出了CakePHP 3的Alpha版本。Cake开发团队将版本3视为改变游戏规则的工具, 因此, 随着版本3的Alpha版本现在热销, 本文采用将CakePHP 3视作一种有效的PHP开发现代框架。
一个简短的历史
如今, 有关PHP开发的选择太多了。随着PHP的成熟, 越来越多的PHP框架应运而生, 为开发人员提供了多种选择。但这并不总是那样。
早在2005年, 当PHP 4仍然是标准时, 还没有PHP框架, 因此在PHP中开发面向对象的编码方法无疑是一个挑战。那时, CakePHP出现了–第一个PHP MVC框架。自从首次发布以来已经过去了近十年, CakePHP继续发展, 保持了PHP开发人员的健康市场份额。
CakePHP框架有多受欢迎？它在GitHub的130, 000个项目中排名前4位最受欢迎的PHP项目中, 在CakePHP Google组中有超过18, 000个成员, 涉及32, 000个主题。有270位代码贡献者和320位文档贡献者, 无可否认, CakePHP拥有大量关注者。 CakePHP基金会的CakePHP核心成员兼社区经理James Watts在一篇文章中很好地总结了CakePHP当前的广泛和日益普及的情况。我在撰写本文时采访了他。
有了框架的第3版, 在当今变化多端的PHP框架中, CakePHP无疑将继续在PHP世界中保持领先地位, 并成为主要竞争者。
CakePHP第3版有哪些新功能？
这篇评论基于CakePHP 3.0的Alpha版本, 其中包含许多新功能和增强功能, 包括：
-
更好的性能。版本3将性能改进合并到引导过程, 路由过程以及过程中的多个部分, 以生成帮助程序模板。
-
增强的组件和助手。第3版通过其新的FlashHelper和FlashComponent为” Flash消息”提供了增强的支持。此外, CookieComponent得到了增强, 可以更轻松地分离cookie名称空间的配置和cookie数据的处理。
-
改进的会话管理。会话管理一直是CakePHP中的静态类, 事实证明它在许多方面都存在问题。在版本3中, 你现在可以从请求对象$ this-> request-> session()访问会话。此更改还使会话更易于测试, 并使CakePHP能够使用PHPUnit4.x。
-
改进了约定的一致性。应用程序框架和插件框架已更新为使用相同的目录结构, 以使彼此之间更加一致。
-
主题和插件已合并。 CakePHP 3的主要目标是使主题变得更强大和强大。朝着这个目标努力, 很明显, 真正需要的是主题提供与插件相同的功能。因此, 现在可以将任何插件用作主题, 这也简化了打包和重新分发。
-
ORM改进。对ORM(对象关系映射)进行了一些API更改。最值得注意的是, 现在可以更轻松地指定用于保存操作的深层关联, 并且已更改了一些约定以减少新使用者的学习难度和混乱。
此外, 还计划将一些其他功能合并到3.0版的beta版本中。最重要的是：
- 国际化和本地化(i18n和L10n)功能增强
- 基于Edge Side Includes的CacheHelper的替代品
- 新的路由API, 可简化和更快地进行路由声明
实际上, 版本3是对CakePHP先前版本的重大升级。
为什么选择CakePHP？
虽然CakePHP具有许多出色的功能, 但本文仅着眼于确实有助于使其与众不同的一些功能, 即：
- 约定优于配置
- CakePHP的ORM(对象关系映射)
- 组件和助手
约定优于配置
CakePHP一直致力于快速一致的开发, 为此, CakePHP十分重视约定。因此, 就像Ruby on Rails(CakePHP从中汲取了很多灵感)一样, CakePHP严格遵守有关配置原则的约定。
约定意味着开发人员在学习如何使用CakePHP框架时不必考虑”问题出在哪里”, 因为这些规则的默认值已经到位。尽管确实需要熟悉CakePHP约定, 但一旦掌握了这些约定, 开发人员便可以专注于核心开发, 而不必担心代码放置在何处以及其他配置问题。
CakePHP的约定与PHP本身形成了鲜明的对比, 后者是一种相当自由的语言。由于其约定, CakePHP有助于确保跨多个开发人员甚至跨多个团队的编码样式和结构具有更大的一致性。通过采用一套标准约定, Cake致力于使开发更加一致。
例如, 对于数据库模式, CakePHP就将如何命名某些变量, 表名和字段做出某些默认假设。具体而言, Cake期望：
- 表格名称将是复数形式(例如订单)
- 主键字段的名称将为id
- 任何外键字段的名称都将基于引用的表名, 后跟_id(例如, 客户表中的外键将被命名为customer_id)。
为说明起见, 我们考虑对博客文章数据库中的两个表(文章和用户)进行简单回顾。在我们的示例中, 我们说的是”属于”用户的Articles, 而用户”有很多”的Articles。这些关系将在CakePHP 3.0中指定如下：
In ArticlesTable.php:
class ArticlesTable extends Table {
public function initialize(array $config) {
$this->belongsTo('Users');
}
}
In UsersTable.php:
class UsersTable extends Table {
public function initialize(array $config) {
$this->hasMany('Articles');
}
}
CakePHP采用默认约定, 因此在获取任何关联时会自动知道要查找的外键(即, articles表中的user_id)。
需要强调的是, CakePHP 3确实允许其默认约定容易被覆盖。例如, 假设我们在用户表中的外键称为author_id而不是user_id。指定它仅需对我们的代码进行以下两个小更改, 以使CakePHP知道我们没有使用默认值：
In ArticlesTable.php:
class ArticlesTable extends Table {
public function initialize(array $config) {
$this->belongsTo('Users' => ['foreignKey' => 'author_id']);
}
}
In UsersTable.php:
class UsersTable extends Table {
public function initialize(array $config) {
$this->hasMany('Articles' => ['foreignKey' => 'author_id']);
}
}
因此, 尽管约定确实是CakePHP不可或缺的一部分, 并且确实具有它们的优点, 但是如我们在此处所示, 在必要时对其进行覆盖确实非常简单。
虽然某些开发人员可能更喜欢不高度依赖约定的PHP框架(例如Yii和Laravel), 但CakePHP约定实际上可以是非常有利的。当他们负责增强或维护由另一个开发人员编写的代码时, 它们可以极大地减少CakePHP开发人员的准备时间, 因为它们可以在多个CakePHP开发人员和项目中实现一致的编码结构和约定。
CakePHP的对象关系映射(ORM)
CakePHP的对象关系映射(ORM)受益于CakePHP的框架约定。通过将数据库架构设置为Cake的标准, 你可以通过Cake强大的ORM将表快速连接在一起。你几乎不需要编写SQL语句, 因为CakePHP可以轻松处理表连接, hasMany甚至hasAndBelongsToMany关系之类的事情。
利用CakePHP的ContainableBehavior, 通过模型关联, 你可以指定要从SQL查询中选择的数据库表和字段。这可以深入几个表, 并且通过ORM可以轻松快速地构建高度复杂的SQL语句。
顺便提及, CakePHP的ContainableBehavior是CakePHP如何简化和简化PHP开发的一个很好的例子。它可以帮助你以干净一致的方式搜索和过滤数据, 还可以帮助提高应用程序的速度和整体性能。 (它通过使用提供的包含来生成相应系列的bindModel和unbindModel调用的临时或永久更改模型的关联来工作。)
ORM面临的挑战是, 它使使用SQL变得如此简单, 以至于如果开发人员不小心, 他或她就可以编写毫无意义的低效率SQL查询。我当然看到过很多编写不佳的Cake应用程序, 但并没有简化他们的查询。这些问题往往会在系统部署后的几年内浮出水面, 这时数据库变得越来越大, 写得不好的查询变得越来越慢。
这里的主要问题是, 在最新的CakePHP版本3之前, Cake的ORM默认会在执行查询时检索任何关联的表。结果, 一个简单的”查找全部”查询可能会变得quite肿, 因为基础SQL将从所有关联表中检索所有数据。在版本3中, 此行为不再是默认行为。 (在CakePHP的早期版本中, 只需将public $ recursive = -1;添加到主AppModel.php文件中, 即可轻松禁用此默认行为。)
总体而言, 对Cake的ORM的评论显示, 它确实确实有助于简化开发, 而且如果使用得当, 它是快速构建复杂查询的绝佳工具。尽管如此, 至关重要的是, 开发人员必须花时间充分理解ORM, 并确保对其查询进行了适当的优化(在任何语言中都是如此)。
组件和助手：CakePHP库
CakePHP的一大功能是内置的库-组件和助手-消除了许多无聊, 重复和乏味的开发任务。在MVC上下文中, 组件可帮助简化控制器开发, 而助手可简化视图编码和逻辑(即表示层)。
例如, PaginatorComponent通过查找查询自动神奇地构建下一个/上一个页面界面。添加JsHelper, 然后突然有了由你最喜欢的JavaScript框架(默认为jQuery)提供支持的AJAX分页。
其他有用的帮助器的快速样本包括：
- TimeHelper：使显示日期和时间变得轻而易举, 并提供了一系列用于格式化和评估时间值的功能。
- NumberHelper：提供方便的方法来显示各种常见(或自定义)格式和精度的数字。
- TextHelper：帮助启用链接, 设置URL格式, 在所选单词或短语周围创建文本摘录, 突出显示文本块中的关键字以及优雅地截断较长的文本。
还有更多。
对CakePHP 3的批评
可以肯定的是, 每个框架都有其优缺点, CakePHP也不例外。以下是本评论之外对CakePHP提出的一些最常见的批评：
-
“遗产框架； and肿且缓慢。”这种批评通常只是一种历史性的批评, 而今天的真理有限(如果有的话)。一直以来, 要支持PHP版本都需要PHP 4, 因此CakePHP必须处理许多PHP自身的遗留问题。随着PHP的日趋成熟, 尤其是CakePHP版本3的发布, 这一指控实际上已经失去了效力。
-
“过于严格和封闭。”尽管CakePHP约定具有明显的优点, 但仍有一些人对其进行了批评。批评家经常争辩说这些约定太严格了, 但是他们没有意识到(或承认)这些约定很容易被推翻。通过采用一套标准的约定, Cake希望使开发保持一致, 考虑到PHP否则采用的宽松编码做法, Cake只能被视为积极的事情。
-
“缓慢的释放周期”。缓慢的发布周期不一定很糟糕。相反, 过于激进的发布周期实际上可能会带来更多问题。实际上, CakePHP主要发行版本需要时间的部分原因是为了确保与仍然广泛部署的早期版本的PHP向后兼容。此外, 这种保守的发布周期以及对向后兼容性的强调消除了在发布新版本时对代码进行重大(频繁)更改的需求。还应该注意的是, 当涉及每月发布的次要发行版(错误修复, 补丁, 次要增强等)时, CakePHP 3团队丝毫没有慢。同样, 大多数错误票在发布后的几个小时内得到答复。
-
“不是开箱即用的解决方案。”与许多其他现代的”开箱即用的Web应用程序” PHP框架(例如Yii)相反, CakePHP故意支持和启用自定义解决方案。通过开发许多大型的, 自定义的, 数据库驱动的网站和应用程序, 我从中受益匪浅。
-
“使用数据数组而不是对象。”从版本3开始, 情况不再如此。在以前的版本中, 所有数据都需要存储并作为嵌套数组引用(例如$ user [‘User’] [‘username’])。 CakePHP 3最终解决了这个问题, 而是将数据存储为对象(例如$ user-> username)。
-
“糟糕的文档。”这种批评是有一定道理的, 因为CakePHP文档似乎并不总是初学者写的(重要的信息有时只用一两句话就可以讨论了, 而讨论的某些段落可能是必要的。 )。 Cake开发团队已意识到这一点, 并正在相应地改进文档。实际上, CakePHP 3文档的主页明确声明了对文档”质量, 有效性和准确性”的高度承诺。由于CakePHP是社区驱动的框架, 因此在文档的每一页上都提供了”改善此文档”按钮, 从而使CakePHP用户能够鼓励他们对文档进行自己的添加, 删除或更正。
总结
总的来说, 在首次发布后近十年的时间里, 对CakePHP的回顾表明, 它仍然是自那时以来出现的许多其他PHP框架的充满活力和强大的竞争者。
CakePHP是一个完整而全面的开发解决方案。代码库很成熟, 功能似乎无穷无尽。总体而言, Cake的建立是为了使开发迅速进行, 这不仅对软件开发人员而且对投资者都很重要。软件开发的最大成本是开发时间的成本, CakePHP旨在大幅减少开发时间。
CakePHP是一个社区运行的项目。随着越来越多的人参与进来, 它只会变得更好。经过7年的参与, 社区不断发展, 我对CakePHP的下一阶段感到很兴奋。 CakePHP 3的发布以及PHP和CakePHP的成熟, 意味着该框架将继续变得越来越好。
如果你正在寻找一个基于PHP的解决方案, 该解决方案提供了许多与Ruby on Rails相似的好处(就易用性和配置约定而言), 那么请让CakePHP焕然一新。 CakePHP博客教程仅需花费几分钟即可设置和运行, 或者, CakeCoded提供了一系列清晰的课程, 以帮助PHP开发人员熟悉CakePHP并开始使用它。有了这些资源, 你将快速了解CakePHP可以在多大程度上加快并增强PHP软件开发工作。请享用！
评论前必须登录！
注册