我应该为 Web“应用程序”使用 Drupal 还是 Kohana 类型的框架答案

【问题标题】：Should I use Drupal or Kohana-type framework for a web "application"我应该为 Web“应用程序”使用 Drupal 还是 Kohana 类型的框架
【发布时间】：2010-04-07 15:17:05
【问题描述】：

争论的焦点是我需要一个 PHP 框架/Drupal，它可以灵活地将自定义功能添加到一个潜在的大型应用程序（Web 和使用 api）。

但是，在使用 Kohana 之类的框架时，我看到自己正在使用帐户管理和 cms 等简单的东西来处理和重新发明轮子。帐户管理和快速数据收集，例如快速创建表单，在 Kohana 中是乏味的，但在 Drupal 中却非常简单。另一方面，基于我有限的 Drupal 经验，我怀疑构建快速自定义“功能”并允许用户创建“组”并在这些组中管理他们自己的角色是 Drupal 可以轻松完成的事情。

简单来说，Drupal 是否能够实现真正的 Web 应用程序？应用程序在哪里是一项服务并向每个用户提供自定义结果？它能否为用户提供一个类似仪表板的界面来更改他们的设置或偏好？它可以汇总来自特定用户的数据以向其他人提供更好的结果/信息吗？

如果是这样，请指点我一些知识:-)

【问题讨论】：

标签： php drupal frameworks kohana

【解决方案1】：

我马上承认我是 Drupal 的忠实粉丝，而且我从未使用过 Kohana，所以这篇文章将是片面的。

在我工作的公司中，他们几乎所有项目都使用 Drupal 或 Zend Framework（Drupal 占大多数）。许多面向 ZF 的人不喜欢 Drupal，因为它的结构与面向对象的 ZF 相去甚远，而 Drupal “只是一个 CMS”。在我看来，Drupal 更像是一个框架，而不仅仅是一个 CMS，最好的部分是它非常灵活：一切皆有可能。

是的，确实有一个模块适用于所有内容。具体来说：

另一方面，基于我有限的 Drupal 经验，我怀疑构建快速自定义 >“功能”并允许用户创建“组”并在 >这些组中管理自己的角色是 Drupal 可以轻松完成的事情。

我只能猜测您对快速自定义功能的意思，但在我看来，使用您自己的模块扩展 Drupal 很容易。大多数功能都可以作为（免费、社区贡献的）模块使用，并且可以轻松创建许多高级外观功能，例如使用“views”和“cck”模块。 http://drupal.org/project/cck http://drupal.org/project/views

创建组： "organic_groups" (http://drupal.org/project/og)
"og_user_roles" (http://drupal.org/project/og_user_roles)

这些模块是您创建具有组特定角色（以及具有特定权限的角色）的组所需要的。除了使用“og_user_roles”之外，可能还有其他方法，但我正在宣传它，因为几年前我已经为它制作了一些补丁。问题通常是选项太多了。

如果您想扩展特定于组的选项，您可以编写自己的模块，但很可能不需要，因为已经有一个模块。例如，至少有 120 个模块以某种方式与“organic_groups”模块集成： http://drupal.org/taxonomy/term/90?page=19

简单来说，Drupal 是否能够实现真正的 Web 应用程序？应用程序在哪里是 > 服务并向每个用户提供自定义结果？它能否为用户提供一个类似仪表板的 > 界面来更改他们的设置或偏好？它是否可以汇总来自>特定用户的数据以向其他人提供更好的结果/信息？

简而言之，是的。有很多方法可以实现您描述的目标。但可能它们至少会涉及到出色的“视图”模块。我认为视图是任何人的某种终极抽象 SQL 层和 UI。并且有超过 300 个模块以某种方式与 Views 集成......（http://drupal.org/taxonomy/term/89?page=55）

这听起来 Drupal 完全是关于模块的。我知道我的一些同事甚至不喜欢它，因为你永远不会编写有趣的东西，因为它已经完成了。至少您可以查看模块代码并从中学习。或者一笑置之，周围也有很多糟糕的编程模块。

当您开始编写模块时，您可能需要大量时间来习惯 Drupal API、Forms API、模块挂钩、主题覆盖系统以及来自 contrib 模块的无穷无尽的选项。但这是值得的。

我发现这个站点对于找到满足某些特定需求的模块非常有用。该站点显示与 Drupal.org 相同的模块信息，但也显示用户反馈/评级，以找到最佳选择： http://drupalmodules.com/

如果不清楚，我的答案是使用 Drupal :)

PS：D7 应该很快就出来了。有些人可能会等待它而不是从 D6 开始。在 D5 期间，由于缺少模块，人们会等待很长时间才能升级到 D6。我相信对于 D7，最重要的模块将很快为 D7 提供。目前的一些研究（04.12.2010）：

大约 190 个模块承诺在 D7 发布之日拥有 Drupal 7 版本： http://drupal.org/project/modules?solrsort=sort_title%20asc&text=d7cx&display=table

D7 已经有大约 130 个模块可用（大部分都包含在上一个链接中）： http://drupal.org/project/modules?filters=drupal_core:103&solrsort=sort_title%20asc&text=d7cx&display=table

编辑：作为一个新手，我只能发布一个链接，所以，我从 drupal.org-links 中删除了 http://

【讨论】：

我不得不承认关于“有机组”的链接很有吸引力。但我也想知道当 Drupal 核心升级时 Drupal 模块运行过时是否会产生严重影响，导致“自定义”修复与升级不兼容。
打补丁可能会导致问题，是的，大多数功能丰富的 Drupal 项目往往需要一两个补丁。但是，您很可能永远不需要修补核心模块（而不是随 D6.x 安装一起提供）。在使用以前的 Drupal 5 版本时，我有时甚至不得不修补核心（一个很大的禁忌）来解决一些问题。但是 D6 更进化并且更易于扩展，因此在 D5 之后，在十几个 D6 项目中，我不必破解任何核心模块。次要核心版本升级，如 6.15 -> 6.16 很顺利：它们只是错误/安全修复，模块仍然可以工作。但是...[文字限制]
... 然而，像 5->6 这样的主要版本不兼容：所有模块都需要升级版本，有时没有（或者您必须切换到替代版本）。打补丁的模块需要重新打补丁。升级曾经是一件令人头疼的事情，例如一次 D4 到 D5 的升级花费了我几个月的计划（一个流行的现场直播网站，当时我是 Drupal-noob.. 借口）。但那是因为它有很多自定义模块和补丁。那时 Drupal 并没有那么流行（更少的模块）。相比之下D5->D6升级很容易，D6->D7应该更容易。 [文字限制]
... 得出我的结论：是的，最好避免修补贡献的模块，如果你必须这样做，你应该在 Drupal.org 的模块问题队列中创建一个问题。开发中的社区真的很有帮助，而且增长迅速，提交自己的补丁并不难。例如，我上周发布了 2 个补丁，它们在 24 小时内得到修复 :)。大多数问题都可以在没有补丁的情况下被覆盖。所有文本输出都是可翻译的，所有输出也可以在主题中覆盖，形式可以完全覆盖等（至少在理论上）。一个警告：太多手动模块 => 缓慢。

【解决方案2】：

我曾使用过 Drupal 和 Kohana。

在我看来，这真的取决于你想做什么。如果您要创建一个需要大量增长并且应该灵活适应其增长的 Web 应用程序，那么我建议使用 Kohana。 Kohana 旨在保持您的代码库清洁并支持 DRY（不要重复自己）。虽然它可能没有 Drupal 那么多模块，但它确实有一些 Auth 和 ACL 模块。

如果您想快速完成并且不介意将您的应用程序与其他模块分开，那么 Drupal 的模块将使您的工作快速完成。但是请记住，当您要扩展时，您很可能会遇到来自您不知道的模块的问题。它还需要你一点灵活性。

最终，这是您的选择。但如果你要从头开始编写，我建议使用 MVC 框架。

【讨论】：

谢谢！你和KO3合作过吗？我正处于 KO2 和 KO3 的十字路口。对 CodeIgniter 2.0 有什么想法吗？
"但是请记住，当您要扩展时，您很可能会遇到来自您不知道的模块的问题。"我完全同意。但是，您可以通过简单地通过它们的来源学习来减少模块的问题。另外，选择最好的模块，通常有很多选择。我通常选择听起来最强大并且拥有最多用户的东西。最后，需要了解主要模块的各种 API，以及它们如何集成在一起。如果您使用 Drupal，您应该咨询具有几年经验的人，以免您学习困难。
@Andres：我只使用 Kohana 2.x。 Kohana 2.x 应用了 MVC 模式。对于大多数项目来说，这种模式应该已经足够好了。另一个 2.x 的专业人士表示有更好的文档可用。 Kohana 3.x 应用了 HMVC 模式，这可以使您的应用程序更加模块化且易于管理。我也非常支持 DRY 方法（google）。看看这里做出你的选择：kerkness.ca/wiki/…

【解决方案3】：

没有不可能完成的事情。问题是您是否想与其他人一起编写代码并尝试弄清楚如何在内部进行挖掘和扩展以便满足您的需求，或者您想使用像 Kohana 或 CodeIgniter（我个人最喜欢的）这样的轻量级框架并驱动你自己的车，虽然你可能需要“发明”一些轮子。

继续研究您选择的框架有哪些插件，因为有很多框架提供了非常好的解决方案，可以为您提供这些轮子。

在我个人看来，您花在学习 Drupal 上的时间将相当于您创建基本 CMS 功能所需的时间，但是您在处理诸如核心 Drupal 代码之类无法控制的事情时所花费的精力将会转移有利于框架的规模。

【讨论】：

但是，一旦您学会了如何编写/修改模块并使用核心 Drupal，您将来就能更快地完成类似的事情。恕我直言，对于打算做这种事情的人来说，Drupal 胜出。
@intuited 我不同意，因为一旦你学会了如何在框架中做事并拥有你的基类，你就有了一个基础，可以随心所欲地去做。如果有人需要灵活性，他应该在他的应用程序中拥有尽可能多的自己的代码，否则那就是一场噩梦。
这取决于你将要做什么.. 如果它在 Drupal 的范围内（很多东西都在），它最终会在 Drupal 中更快地完成，特别是一旦你克服了如何将 Drupal 扩展到其基本功能之外的初始学习曲线。 Drupal 基本上是一个框架，但比大多数框架更高级、更具体。
@intuited 我对 Drupal 和 Joomla 等系统的经验是，他们试图以最通用的方式完成 1000 件事情，这需要大量非专业代码，这在我看来使它们非常臃肿。我每次都会使用像 CodeIgniter 这样的框架并构建自己的东西。这就像买一套西装，你可以在裁缝店订或从商店买，猜猜哪一件最适合你。

【解决方案4】：

关于 Drupal 的有趣之处在于社区开玩笑地称之为第 35 条规则：它有一个模块。除非您想做一些非常棘手的事情，否则您通常会发现该功能已经实现，您只需要配置它即可。

【讨论】：

甚至还有一个 drupal 模块，它为每个节点添加一张有人在内衣中安装该模块的图片。

【解决方案5】：

我是 Drupal (7.12) 和 Kohana (3.2.0) 的新手...到目前为止，我的经验是 Kohana 的文档很烂（或者至少，我所看到的）。如果他们的网站和/或论坛是用 Kohana 编写的，那么它也很糟糕（slooooow，有重叠的字段等）。而对于 Drupal，它一直很干净，到目前为止，非常有效（到目前为止我能说的最好）。

我想我想知道到目前为止，cmets 是否专注于 Drupal 6.x，而没有考虑到 Drupal 中最近的创新。有什么想法/cmets？谢谢。

【讨论】：

【解决方案6】：

作为新手 Web 开发人员，我可以告诉您，您需要非常严格地分析 Web 应用程序的用例。如果您能够涵盖至少 75% 的预见用例，那将是一个好的开始。

完成后，您需要确定 Drupal/Joomla/CMS(x) 是否会为您提供所有这些功能以及另一个潜在的未知 5-10% 功能蠕变。如果是这样，您最好还是使用 Drupal 等。

另外，我认为 CodeIgniter 或 Symfony 是很好的 PHP 框架。两者都提供可靠的教程、视频和其他方式，以及一个有用的社区。 Kohana，我正在研究，我认为如果你真的了解 PHP 及其缺陷并意识到速度将是一个关键因素，你应该进入。这是 KO3 带来的两大优势，您真的应该需要他们来使用它。

希望这会有所帮助。

【讨论】：