2

私はSymfony2にかなり慣れていません...

私の問題:

バンドルが相互に直接参照しないようにするにはどうすればよいですか?私は物事を可能な限り緩く結合させようとしています。必要に応じて例外や依存関係が存在する可能性がありますが、相互に参照する多くのバンドルの構築を開始したくありません。

例:

いくつかの単純なCMS機能をサイトに追加している間、私は現在これらのバンドルを持っています:

  • src:AdminBundle-SonataAdminを使用します
  • src:MainBundle-メインサイトとDoctrineエンティティクラスが含まれています
  • ベンダー:Sonata-管理者

したがって、AdminBundleはMainBundle内で提供されるエンティティと連携する必要があります。その結果、src / AdminBundle / Resources / config/services.ymlに次のようなエントリがあります。

services:
    pwn.admin.page:
        class: Pwn\AdminBundle\Admin\PageAdmin
        tags:
            - { name: sonata.admin, manager_type: orm, group: Content, label: Pages }
        arguments: [null, Pwn\MainBundle\Entity\Page, null]

MainBundleへの参照は、私が避けようとしているものです。必要に応じて、おそらく別のバンドルからでも、別のORMオブジェクトを簡単に指定できるようにしたいと思います。

全体として、app /config/内のファイルのみがすべてのコンポーネントを接着するようにしようとしています。ただし、場合によっては、バンドルが一方向に厳密に依存していても問題ないと思います。私のAdminBundleはSonataAdminに依存しています。

オプション:

  1. サービス定義全体をsrc/AdminBundle / Resources / config/services.ymlからapp/config / config.yml(またはconfig_admin.ymlなどのインクルードファイル)に移動します。ただし、これにより、構成が少し肥大化したり、サービス定義が繰り返されたりする可能性があります。これらの重大な問題はありますか?

  2. パラメータを使用するようにarguments行を変更します。例:arguments:[null、%admin.entity.page%、null]各エンティティのパラメータは、app / config/config.ymlで指定できます。ただし、これを広範囲に行うと、「parameters」名前空間に多数のエントリが作成される可能性があり、それが意図された用途ではないと思いますか?

  3. ここで説明されているように、サービスコンテナ拡張機能を使用して新しいサービスを作成します:http ://symfony.com/doc/current/book/service_container.html#importing-configuration-via-container-extensions 。正直なところ、そのようなサービスがどのようにしてsonata.adminグループに登録され、SonataAdminにピックアップされるのかわかりません。

  4. 定義全体をResources/config / services.ymlに残し、今後も比較的簡単に変更できることを嬉しく思います。

ヘルプ/コメントは大歓迎です。私のアプローチ全体が間違っている場合は、言ってください。:)

4

0 に答える 0