一尘不染

Symfony2概念问题：普通捆绑包与特定捆绑包

php

编辑：Symfony最佳做法回答了我的大部分问题。

关于我的Symfony2应用程序，我有几个问题。

它将有一个前端和一个后端，并且它们将使用一些通用代码（例如日期显示器，分页器，一些经常使用的模板等）。

因此，我创建了一个FrontendBundle和一个BackendBundle，它们分别包含各自的布局。第一个问题：为前端和后端创建捆绑包（这是甚至没有控制器的“通用”捆绑包）的优良作法吗？

第二个问题：我读过一本食谱，不应该将布局放在成束的东西中，而应该放在app / Resources / views
/目录中。我已经有一个base.html.twig文件了，我想知道是否也应该像frontend_layout.html.twig文件一样放置布局？

我创建了一个名为RootBundle的捆绑包，其中包含我的应用程序在前端和后端所需的所有内容。这是一个好习惯吗？或者我应该为提出的每个功能创建专用的包，例如PaginatorBundle，DateDisplayerBundle等？我有一个“杂项”捆绑包，其中包含我不知道放在哪里的所有东西，这听起来很奇怪。你是怎样做的？

阅读 181

2020-05-26

共1个答案

一尘不染

新方法

自从我写了这个答案几个月后，我的方法发生了变化，因此我要与社区分享。这个答案仍然很受欢迎，并且可以使新来者采用我认为不再是最好的方法。所以…

现在我只有一个 特定于应用程序的 捆绑包，我称之为AppBundle。旧方法存在一些问题，其中一些是：

创建很多捆绑包是乏味的。 您必须为每个新捆绑包创建捆绑包类和一堆标准文件夹，然后将其激活并注册其路由和DI等。
不必要的核心决策过程。 有时，您无法确定特定事物属于哪个捆绑包，因为它被多个捆绑包使用。在花了半天时间并最终决定将其放置在哪里之后，您会发现，在几天或几周内，您将无法立即分辨出将哪个东西放在哪个捆绑包中-因为在大多数情况下，决策并非基于纯粹的逻辑，因此您不得不基于抛硬币或其他手段来做出选择，以借助更大的力量来寻求帮助。

我CommonBundle过去建议使用常用的东西，但是这样做必须CommonBundle基于以后会使用多少个捆绑软件来进行很多不必要的重构。

无论如何，特定于应用程序的捆绑包是相互依赖的。 当人们第一次遇到捆绑的想法时，他们脑海中流传的主要思想是“是的！我要一堆可重复使用的捆绑包！” 这个主意很棒，我对此毫不反对。问题在于，特定于 应用程序的 捆绑包无论如何都无法重复使用-相互依赖。在这种情况下，请不要重用。
不知道在何处放置 Behat功能和步骤定义。这个问题与先前的问题有关：您必须为每个捆绑重复相同的无脑动作，然后做出硬性决定。

当我开始编写Behat功能时，我只是无法决定将许多功能和步骤定义放在哪里，因为它们一次属于几个捆绑包。把它们放进去CommonBundle似乎更加糟糕，因为那是我要寻找的最后一捆东西。因此，我最终FeatureBundle为此创造了东西。

切换到单个捆绑包解决了所有这些问题。

我还看到有些人为所有实体提供了单独的捆绑包。我也不喜欢这种方法，实际上建议不要将实体和其他非Symfony2特定的东西放进捆绑包中

再次注意，此新方法适用于特定于 应用程序的
捆绑包。官方文档和其他地方对如何构建旨在与他人共享并在多个项目中重复使用的捆绑软件提供了很多建议。我也写这种类型的捆绑包。但是，经过几个月的Symfony2项目研究，我发现用于重用的捆绑包和针对特定应用的捆绑包之间存在差异–一种方法并不适合所有情况。

而且，当然，当您看到特定于应用程序的捆绑包中出现了可重用的东西时，只需将其提取出来，放在单独的存储库中，然后作为供应商安装即可。

另外，我发现自己更积极地使用子命名空间，以此作为对捆绑包进行逻辑分区的一种方法，而不是为此创建一堆捆绑包并解决了所有这些麻烦。

旧方法

没有硬性规定，也没有灵丹妙药，但我将分享我的处事方法-也许它将为您提供一两次见识。

首先，我没有这两个包罗万象捆状FrontendBundle和BackendBundle。相反，我的包同时具有前端和后端控制器，视图等。因此，如果我从UserBundle控制器中剥离除控制器和视图之外的所有内容，其结构将如下所示：

UserBundle
├── Controller
│   ├── Admin
│   │   └── UserController.php
│   └── UserController.php
├── Resources
│   └── views
│       ├── Admin
│       │   └── User
│       │       ├── add.html.twig
│       │       ├── delete.html.twig
│       │       ├── edit.html.twig
│       │       ├── form.html.twig
│       │       └── index.html.twig
│       └── User
│           ├── edit.html.twig
│           ├── sign-in.html.twig
│           ├── sign-up.html.twig
│           └── view.html.twig
└── UserBundle.php

其次，我有CommonBundle几个捆绑共享的东西：

CommonBundle
├── Resources
│   ├── public
│   │   ├── css
│   │   │   ├── admin.css
│   │   │   ├── common.css
│   │   │   └── public.css
│   │   └── img
│   │       ├── add.png
│   │       ├── delete.png
│   │       ├── edit.png
│   │       ├── error.png
│   │       ├── return.png
│   │       ├── success.png
│   │       └── upload.png
│   └── views
│       ├── Admin
│       │   └── layout.html.twig
│       └── layout.html.twig
└── CommonBundle.php

我的产品app/Resources/views/base.html.twig与Symfony Standard发行版中的产品几乎相同：

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8" />
        <title>{{ block('title') | striptags | raw }}</title>
        {% block stylesheets %}{% endblock %}
    </head>
    <body>
        {% block body %}{% endblock %}
        {% block javascripts %}{% endblock %}
    </body>
</html>

无论CommonBundle/Resources/views/layout.html和CommonBundle/Resources/views/Admin/layout.html扩展app/Resources/views/base.html.twig。其他捆绑软件的模板扩展了这两种布局之一，具体取决于它们是用于前端还是后端。基本上，这就是我使用三级继承方法的方式。

因此，我会将您的日期显示工具放入CommonBundle。根据其复杂性，它可能只是模板，宏或Twig扩展。

分页是一个常见问题，因此，我建议您使用现有的捆绑软件之一，而不要重新发明轮子-当然，如果它们满足您的需求。

是的，拥有没有控制器或视图等的捆绑包是完全可以的。

2020-05-26