Drupal 作为框架答案

【问题标题】：Drupal as frameworkDrupal 作为框架
【发布时间】：2011-10-02 16:11:41
【问题描述】：

我们可以将 Drupal 用作大型应用程序的框架吗？是否适合在其框架中开发大型应用程序，或者有什么限制？

我想在我的应用程序中使用 Drupal 作为框架。值得吗？

【问题讨论】：

更具体。每个框架都有其局限性，但是当您在描述您的应用程序时给我们的唯一内容是“大”时，很难知道 Drupal 的局限性是否会影响您。
您想实现哪些功能？
我想实现系统管理员向系统所有者授予许可的许可管理。系统所有者将购买许可证。和系统管理员创建没有。系统所有者的。在系统所有者下将有 0-n 个自定义用户。
@RPM，还有审核系统。在那幅画中，审稿人和作者出现了。为了进入系统，他/她必须登录，所以不会有任何前端（匿名用户）侧内容显示。所以，为此我很困惑是否必须使用 drupal 或任何其他框架。

标签： drupal frameworks content-management-system

【解决方案1】：

如果您正在寻找开发-框架，Drupal 可能不是正确的选择。如果您正在寻找构建网站的套件，Drupal 可能是合适的工具。

人们经常说 Drupal 是一个 CMF，其中 F 代表 Framework，但实际上，Drupal 只是一个灵活的 CMS。

在高层次上，Web 应用程序框架 分为两类：MVC 和 CMS。模型视图控制器是大多数人所说的框架。 CMS 只是一个具有应用程序开发能力的灵活 CMS。

在实践中，Drupal 缺乏的是：

正确的架构。 Drupal 中的大多数东西都是有机进化的；这会导致不一致、意外行为和意外障碍。并不是说 Drupal 没有正确构建：只是说它没有被架构：设计为一个整体。
最少意外原则。许多框架允许熟练的开发人员在几个小时内创建站点。使用 Drupal，您必须获得大量经验和最佳实践，然后才能有信心在规划中推出网站。
MVC。 Drupal 有一个独特的数据库层和一个主题（视图）层，但它们是非常规的，并且经常被误用。当然不是在结构模式之后。
无主见的行为：框架可以强制执行某些方法、库甚至鼓励某些行为，但它不应该有硬编码/不可覆盖的默认值来指示您的最终产品。或者，用英语：Drupals 核心有许多默认值，它们决定了您将如何设置、布局和构建您的网站，而不管您（客户）的需求或愿望如何。模块或插件更经常带有行为，并且通常看起来是内置的和/或硬编码的。
DRY，不要重复自己：Drupal 严重依赖于重复自己。它的整个主题系统依赖于将代码片段复制到自定义文件中并更改花絮。它的表单覆盖系统需要将默认表单的大部分内容复制到自定义模块中，并更改想要修改的部分。

从我 10 多年的 Drupal 经验中可以看出，其中许多缺陷是延迟和预算下滑的主要原因。在我参与的大多数项目中，无意见的行为部分被证明是最令人讨厌的。表面上简单的功能或想法被证明占据了整个预算的大部分；微小的细节吞噬了开发周；最后的 20% 不仅需要 80% 的努力，有时还需要 300%。

除此之外，Drupal 不遵循 OO 模式，这（根据普遍共识）是一件坏事。没有继承，没有 DRY-practice，没有 object-relation-mapper*) 也没有 unittesting-practice.**)。

这可能听起来很消极，但实际上，尽管存在所有这些“缺点”，但人们还是设法建立了不错的 Drupalsite。这是因为它们主要遵循 Drupal 的默认设置（可能的标准，需要更改的插件，没有其他选项时的自定义开发）。

*)其实有；在 Drupal 7 中，引入了 PDO，但没有（还没有？）用作 ORM。

**) 事实上：所有核心和许多贡献都有测试，但这些是集成测试和罕见的单元测试。集成测试 (DrupalWebTest) 为每个测试安装一个干净的 Drupal 代码库+数据库。您的平均核心测试套件运行时间超过 8 小时也不例外。 TDD 根本（还）不可能。

编辑阅读您的示例：Drupal 在“表单向导”领域特别糟糕，尽管在 Drupal 7 中有所改进。Drupal 中另一个值得注意的不足是适当的、可编程的工作流系统。有几个模块可以增强或替换核心中的简单工作流系统，但它们并不容易编程，也不是有效的（开发努力方面）。 听起来像是您想要的主要功能，位于 Drupal 中最不发达的地区

【讨论】：

我与 Drupal 合作并且（仍然）喜欢它，但这些评论家非常有思想。
很好的答案。我从事 Drupal 开发已有 4 到 5 年，并且对此持批评态度。很高兴看到其他人不随波逐流并批判性地思考。
@Alexander：我愿意讨论每一个，然后改变我的帖子。但这不是进行此类讨论的合适场所。如果您不同意，请发布您认为更好的答案。
+10 年经验？恕我直言，您提出的大部分观点都是纯属胡言乱语。 Drupal 支持 OOP，尽管该框架不是围绕 OOP 原则设计的。 Drupal 支持单元测试，它集成在核心中。我会在这里停下来，但我可以从这篇文章中讨论许多其他观点。
@stefgosselin：我没有说 Drupal 不支持 OOP，只是说（你似乎同意）它不遵循 OOP 模式。我也没有说它缺乏对单元测试的支持，只是很少，而且它们主要是集成测试，而不是单元测试。所以，与其停在那里，你可能只是进一步阅读了我实际陈述的内容。

【解决方案2】：

这实际上取决于您的应用程序的需求。 Drupal 虽然灵活且可扩展，但它首先是一个 CMS，并且加载了 Web 应用程序可能需要也可能不需要的功能。但是，如果开箱即用或带有附加模块，它可以为更经典 Web 应用程序功能（即用户管理、内容管理、插件系统、主题层等）、Drupal 提供大量匹配提供了一个很好的框架来避免重新发明轮子（或依赖第三方/不太成熟的框架插件）。

与大多数框架相比，Drupal 的学习曲线更陡峭。作为一个框架，Drupal 是为 CMS 构建和设计的。从历史上看，Drupal 几乎将所有内容都放在数据库中。随着exportables 和Features module 等工具的推广，情况现在变得更好了。此外，与大多数框架 Drupal does not use MVC 不同，它大多不是面向对象的。

【讨论】：

简单说一下：将数据放入数据库有什么问题？
@Juliusz：Drupal 已经做出了将几乎所有配置和数据都放入数据库的设计决策。这让我经常发疯。我必须使用配置部署预填充的数据库，而不是部署配置文件。
@Juliusz：配置数据要放入数据库吗？数据查询页面是使用 UI（即视图）构建的，还是使用 UI（即内容类型）构建的内容结构将数据放入数据库？
@ZeroPage - 公平点，但另一方面 - 您可以通过数据库连接控制应用程序。因此，无法对许多服务器快速进行远程登录和更改。我也不明白“预填充数据库”这一行。您是指在数据库上运行脚本，还是直接复制和挂载二进制文件？
@mongolito404 据我所知，Drupal 站点配置是通过配置文件完成的？对于视图和内容类型 - 我不知道，也许将它们存储在文件中会更快。我们可以在 drupal.org 的某个地方问这个问题。为了方便起见，我宁愿将所有内容都放在 db.xml 中。恕我直言，通过 SQL 更改节点或内容非常有用。其次 - 当您备份数据库时，您知道您一次性存储了整个站点（除了图像）。它也很有用（如果您没有修改原始文件）。所以仍然很高兴听到为什么这不是一个好主意。

【解决方案3】：

是的！您可以将其用作框架。您可能希望对一些核心 API 感到满意，例如菜单、节点和可能的表单 API。菜单路由器和访问控制相当不错。

我曾在几个 Drupal 网站上工作过，但由于核心需求与 CMS 几乎没有关系，所以这些网站都无法正常工作。 Drupal 非常灵活，但它最适合内容管理。您当然可以将它用作其他应用程序的卫星 CMS。 Drupal 也可以用于服务驱动的架构。

如果您想扩大规模，您可能会考虑一个更重视测试和测试驱动实践的框架。 Drupal 是这些实践的较晚采用者，并且在该领域并不成熟。这让我感到沮丧，尤其是在回归错误成为问题的大型网站上。如果您对此感兴趣，请考虑使用 Ruby on Rails 之类的东西。

祝你好运！

自我提醒：我为什么要祝某人在软件项目上好运？ ... 有趣。

【讨论】：

【解决方案4】：

Drupal 8 变化很大。

- It is OOP
- Using Composer
- Have good cache mechanism in core
- RESTful in core

所以现在它可以很容易地用作任何应用程序的框架。在网络端，所有方式都有内容。电子商务有内容。等等。

【讨论】：