Drupal模块的最佳应用工作流隐喻是什么？ 在PHP框架中，我们认为MVC风格。我们如何看待Drupal？Drupal模块内部工作的隐喻
Asumming我在写一些面向用户的模块，如Shop，Catalog或Forum。 据我了解，没有或很少的MVC模块。 我通常应该将Drupal模块（作为子应用程序）当作通过表单和超链接连接的多个 屏幕，或者有更好的方法。
我的问题可能有点推测，但我希望有人会分享我的思维模型，而不仅仅是“脚本”。
Presentation-abstraction-control（PAC）似乎是描述的事情Drupals一般方法的模式最接近的比赛，但我想这或多或少是偶然的;）
的分层组织（或多或少）独立PAC三元组可以粗略地映射到Drupal模块，它们或多或少都是独立的代理，在三个领域（视图，控制器，模型/抽象）中发挥作用。
Model-view-presenter还定义了一些方面，可以在Drupal被发现，尤其是在该视图不直接从示范利用其内容从MVC的偏差，但是从控制器，从而使信息的流动是严格View<>Controller/Presenter<>Model。
但是，Drupal中关注点的分离（截至目前）非常不正式，并且很大程度上取决于开发人员的编码规则，因此始终处于完全崩溃的边缘（有许多模块将大量逻辑进入主题层，或多或少地进入视图）。
也就是说，不执行分离严格似乎是原因Drupals成功的一个，因为它允许各种各样的人非常不同的背景，而无需进行培训，开发者贡献。例如，PHP的知识缺乏的HTML/CSS盖伊从他个人的模板内实现相当大量的调整和补充功能，而无需实现完全成熟的模块。如果他的所作所为是普遍关心的，它迟早会演变成其他人拿起它一个更正式的结构/模块。对于喜欢玩游戏的人，兴趣爱好者和初学者开发者来说也是如此 - 即使他们没有真正理解正在发生的事情，他们也可以完成他们的目标，所以他们的功能理念可以被添加到贡献中，并且可以被完善，只要他们符合一般兴趣。
到目前为止，这工作得很好 - Drupal的核心得到了更正规的;与每一个主要版本，同时仍保持对附加功能的灵活性 - 让我们来看看这是否会在未来撑起（以下scriptish） ...
在drupal中的模块被认为是一个函数集合（实现drupal的“钩子”），当引擎中发生某些“事件”时被调用。这些不是严格的用户事件，而且还有，例如，加载阶段（加载节点之前，加载节点之后等）或检查（引擎正在检查权限，是否要添加一些？ ）。
实际上，钩子是扩展drupal功能的函数，因此您可以将自己的行为添加到drupal提供的行为中。然后Drupal会在适当的时间调用这些钩子，以便您执行您的操作。
因此，与表单或页面没有紧密联系，并且与MVC模型没有任何关系......从版本6开始，drupal不是基于对象的。
这是严格的drupal部分。你的模块建立在此之上，但它可以使用任何你想要的架构。它可能是面向对象的，它可能使用MVC或任何其他模式。
这是一个高水平的问题，但我会刺。
Drupal是一个内容管理框架，有一个很好的概述here.
Drupal是一些object orineted principals bassed。它与MVC非常类似，关注点很多。有一个database abstraction layer，一个逻辑层和theming system。
当编程一个drupal模块时，通常建议使用一个或多个可用的hooks。这将使您可以将代码紧密集成到Drupal系统中。 core内置了很多功能，您可以在模块中使用这些功能。利用这些将减少您必须编写的代码，并使代码更加小心翼翼。
Drupal的挂钩被称为侦听器，或者在大多数OO语言Observers。 虽然他们在技术上folluw这种模式，不要指望polishedness和成熟，你会在大多数面向对象语言和环境的发现。 Drupals挂钩可能极不一致，使用受限或使用范围太广。
听众，钩，大约在Drupal一切的核心架构原则。
然后Drupal应用程序听起来更像基于事件的应用程序，作为一般类别。 – AlexA 2009-08-24 10:25:07