Drupal作为框架

Question

我们可以使用Drupal作为更大应用程序的框架吗？它是否适合在其框架中开发大型应用程序,还是有任何限制？

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

Answer 1

如果您正在寻找开发框架,Drupal可能不是正确的选择.如果您正在寻找建立网站的套件,Drupal可能是正确的工具.

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

从较高层面来说,Web应用程序框架分为两类:MVC和CMS.模型视图控制器是大多数人称之为框架的.CMS只是一个具有应用程序开发能力的灵活CMS.

实际上,Drupal缺少的是:

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

其中许多缺乏是导致延误和预算下滑的主要原因,正如我在10年的Drupal经历中所看到的那样.对于我所参与的大多数项目来说,未经宣传的行为部分已被证明是最令人讨厌的行为.明显的简单特征或想法证明占据了整个预算的很大一部分; 微小的细节吞噬了发展周; 最后20%不仅占80%的努力,而且有时占300%.

除此之外,Drupal不遵循OO模式,(根据普遍的共识)这是一件坏事.没有继承,没有DRY-practice,没有对象关系映射器*),也没有单元测试 - 练习.**).

这听起来可能都是消极的,但实际上,尽管存在所有这些"缺点",但人们还是设法建立了漂亮的Drupalsites.这是因为它们主要遵循Drupal的默认值(尽可能标准,需要更改的插件,没有其他选项的自定义开发).

*)实际上有; 在Drupal 7中,引入了PDO,但是(还没有)将ORM用作ORM.

**)实际上:所有核心和许多贡献都有测试,但这些是集成测试和罕见的单元测试.Integration-tests(DrupalWebTest)为每个单独的测试安装一个干净的Drupal-codebase +数据库.您的平均核心测试设备运行时间超过8小时也不例外.TDD根本不可能.

编辑阅读您的示例:Drupal在"表单向导"方面特别糟糕,尽管它在Drupal 7中有所改进.另一个值得注意的缺点是Drupal,它是一个适当的可编程工作流系统.有几个模块可以在核心中增强或替换简单的工作流系统,但它们并不容易,也不容易(开发工作)进行编程.这听起来像你想要的主要功能,是Drupal中最不发达的领域

Answer 2

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

与大多数框架相比，Drupal 的学习曲线更陡峭。作为一个框架，Drupal 是为 CMS 构建和设计的。从历史上看，Drupal 几乎将所有内容都放在数据库中。现在，随着可导出内容和功能模块等工具的推广，情况有所好转。此外，与大多数框架不同，Drupal不使用 MVC，并且大多不是面向对象的。