【问题标题】:Structure of logic in Symfony appSymfony 应用程序中的逻辑结构
【发布时间】:2013-09-25 07:23:39
【问题描述】:

我对 symfony 框架很陌生,对于一个新项目,我想确保我得到了正确的设置。该项目本身将具有前端和后端,并将包含多个模块,例如博客、论坛、新闻文章等。

每个模块都将成为一个捆绑包。这对我们来说似乎是最好的解决方案。我们希望能够取出一个捆绑包并用不同的捆绑包替换它。因此,例如,我们可能有 2 种不同类型的博客包,如果需要,我们可以交换它们。因此,与模块相关的所有设置和其他部分都在同一个包中是非常重要的。

现在,问题将是每个模块的设置将跨越不同的页面。例如,博客和论坛上 cmets 的排序顺序将在同一页面上配置,远离您管理博客文章的页面。每个模块的上传设置将在不同的页面上。等等

对我来说,这些设置以某种方式在指定的博客和论坛捆绑包上更新,这听起来最合乎逻辑。所以所有部分都在一起。或者,负责设置的页面可能以某种方式能够找到哪些模块具有此类设置并进行检索。

解决这个问题的最佳架构是什么?

-- 编辑--

博客文章、博客 cmets、博客上传,都是一个博客包的一部分。博客包的设置也不会出现在论坛包中。我的意思是捆绑包中有一个单独的页面,称为“设置”,负责处理应用程序的所有设置。它还应该处理每个捆绑包的设置。因此,您可以在同一页面上编辑博客设置和论坛设置,并且此页面不属于任何论坛或博客包。

【问题讨论】:

    标签: php symfony architecture


    【解决方案1】:

    为博客提供一个捆绑包:好的,为博客文章提供一个捆绑包,另一个为 cmets 提供一个包,这非常非常糟糕。因此,您当然可以为您的捆绑包创建一个设置页面,并且您可以让您的应用程序的核心在每个页面之间创建链接。

    但是,如果您需要在不同捆绑包上的页面上进行设置,那么您的应用程序的结构就会很糟糕。对于一个功能,使用服务,对于一组链接在一起的功能,使用一个包。

    ---- 编辑 您的捆绑包必须在其自己的捆绑包中有一个设置页面。您可以使用 twig 轻松添加它们,但您始终需要自己制作此模板(这很正常)来创建您的设置页面。如果你有一个参数被多个包使用,你可以在同一个地方注册这个参数并将你的模板剪切为每个参数都有一个块,然后在你的完整模板中包含你需要的那个。

    但这很奇怪,在我看来,每个包一个设置页面是一个好方法,冗余参数是不好的,因为今天你想要相同的设置来对博客和论坛的 cmets 进行排序,但明天,也许你会想要有区别。

    这是我的观点,不是“解决方案”;)

    【讨论】:

    • 我不会为每个部分创建单独的捆绑包。博客是一个捆绑包,包含文章和 cmets。让我编辑我的帖子来解释一下
    猜你喜欢
    • 1970-01-01
    • 2013-10-09
    • 1970-01-01
    • 2016-04-24
    • 2015-11-10
    • 2016-09-09
    • 1970-01-01
    • 2013-04-12
    • 1970-01-01
    相关资源
    最近更新 更多