web-dev-qa-db-ja.com

Symfony 4：フォルダー構造（つまり、ビジネスロジック）を整理する方法

Symfony Best Practices では、ビジネスロジックを整理するためにバンドルを使用しないことをお勧めします。

バンドルは、それらのコードが他のアプリケーションでそのまま再利用されることを意図している場合にのみ使用する必要があります。

ただし、バンドルとは、スタンドアロンのソフトウェアとして再利用できるものを意味します。 UserBundleを他のSymfonyアプリで「そのまま」使用できない場合、それを独自のバンドルにすべきではありません。

ですから、Symfony 3.3からSymfony 4にアプリをアップグレードしているので、コードを再編成するのが適切な時期だと思います。

現時点では、「バンドル構造」に従っています。

- src
   - AppBundle
      - Controller
      - Entity
      - Repository
      - Resources
      - ...
   - MyNamespace
      - Bundle
          - BundleTodo
              - Controller
              - Entity
              - Repository
              - Resources
              - ...
          - BundleCatalog
              - Controller
              - Entity
              - Repository
              - Resources
              - ...
          - BundleCart
              - Controller
              - Entity
              - Repository
              - Resources
              - ...
          - ...

さて、新しいディレクトリ構造で、どのようにコードを整理する必要がありますか？

このように整理したいと思います。

-src
   - Core
      - Controller
      - Entity
      - Repository
      - ..
   - Todos
      - Controller
      - Entity
      - Repository
      - ..
   - Catalog
      - Controller
      - Entity
      - Repository
      - ..
   - Cart
      - Controller
      - Entity
      - Repository
      - ...

しかし、これは正しいですか？ Symfony 4およびFlexの予想されるフォルダー構造に問題はありますか？

または、このようなものの方が良いです：

-src
   - Controller
       - Core
       - Todos
       - Catalog
       - Cart
       - ...
   - Entity
       - Core
       - Todos
       - Catalog
       - Cart
       - ...
   - Repository
       - Core
       - Todos
       - Catalog
       - Cart
       - ...
   - ...

プロジェクトディレクトリ構造 （オーバーライド方法について）で説明されている他のルートフォルダにも同じことが当てはまります。

新しいフォルダー構造を決定する際に考慮しなければならないルールや制約はありますか？

問題を解決しようとする

それで、問題を解決しようとして、私はドキュメンテーションをより深くし、見つけたものをここに書きます。

symfonysymfony4
23
Aerendir

コメントで述べたように、Symfonyはこれらのすべての構造でうまく機能するので、実際にここで受け入れられるアンサーを持つことはできませんが、ここに私の2セントがあります。

正直に言うと、ベストプラクティスは、フレームワークから独立してアーキテクチャを整理することです（主にこの理由から、Symfony 4はバンドルを課しません）。

しかし、実際には、本当に特定のプロジェクトや複雑なプロジェクトを除いて、「symfony指向」の組織がより実用的です。

以下は私の個人的な好みですそして私のプロジェクトの類型にも強く影響されます（強力なビジネスロジックのないCRUD指向、REST API）

一般に、私はこのような構造に向かっています：

-src
   - Controller
       - Core
       - Todos
       - ...
   - Entity
       - Core
       - Todos
       - ...
   - Repository
       - Core
       - Todos
   - Validator (or other Symfony oriented components)
       - Core
       - Todos
   - Others (depend on project)
       - Core
       - Todos
   - ...

その理由は次のとおりです。

  • Autowireによるサービス定義の削減-ええ、私は怠け者です;-)

    リポジトリまたはコントローラーをサービスとして登録する必要がある場合は、1つの宣言で登録できます。

  • Symfony Flexのレシピでは、通常、この構造が使用されます。

    たとえば、DoctrineBundleはsrc/Entityおよびsrc/Repositoryフォルダーとエンティティを含むレシピもこの構造を使用します。

ただし、Symfony Flexは必須ではないことに注意してください。その目的は、主にプロジェクトの初期化を容易にし、初心者がフレームワークにアクセスしやすくすることです

8
j-guyon

2番目の構造は、ビジネスエリアが分割された複雑なアプリに非常に適しています。
Symfony 4では、この方法でアプリケーションを簡単に設定できます。

├─ assets/
├─ bin/
│  └─ console
├─ config/
│  ├─ doctrine/ 
│  │    ├─ core/
│  │    └─ sample/
│  ├─ packages/
│  ├─ routes/
│  └─ validator/
│  │    ├─ core/
│  │    └─ sample/
├─ public/
│  └─ index.php
├─ src/
│  ├─ Core/         
│  │  ├─ Controller/
│  │  ├─ Entity/
│  │  ├─ Repository/
│  │  └─ ...
│  ├─ Sample/      
│  └─ ...
├─ templates/
│  ├─ core/
│  └─ sample/
├─ tests/
├─ translations/
├─ var/
│  ├─ cache/
│  ├─ log/
│  └─ ...
└─ vendor/

少しの設定で：サービスの自動配線、自動設定などが魅力のように機能します。

# config/packages/doctrine.yaml
doctrine:
    # ...
    orm:
        # ...
        auto_mapping: true
        mappings:
            App\Core:
                is_bundle: false
                type: yml
                dir: '%kernel.project_dir%/config/doctrine/core'
                prefix: 'App\Core\Entity'
                alias: 'AppCore'


#config/routes/annotations.yaml
core_controllers:
    resource: ../../src/Core/Controller/
    type: annotation


# config/services.yaml
# But I prefer to put this on a separate config/services/_auto.yaml
services:
    App\:
        resource: '../../src/*/*'
        exclude: '../../src/*/{Entity,Migrations,Tests,Kernel.php}'

    app_controller:
        namespace: App\
        resource: '../../src/*/Controller'
        tags: ['controller.service_arguments']
6
Benito103e

コンウェイの法則：

システムを設計する組織は、これらの組織の通信構造のコピーである設計を作成するように制限されています。

作業を整理する方法を中心にディレクトリ構造を設計する必要があります。

あなたまたは同僚が機能ごとにフルスタックで作業している場合、機能ごとにコードをグループ化する必要があります。これにより、ナビゲーションとコード検出が容易になります。

あなたまたはあなたの同僚がバックエンド、フロントエンド、翻訳などに精通している場合は、その周りにコードを整理する必要があります。機能ごとのディレクトリ構造は、責任の明確な分割をサポートします。

また、深さはプロジェクトの大きさによって異なります。 5年以上の5年以上の努力が必要な場合は、前述のように、作業組織に応じて、機能ごとおよびネストごとに機能ごとに分割する必要があります。 1人で3か月のプロジェクト、つまり単純な内部ツールを使用する場合は、おそらくよりフラットな構造にする必要があります。また、デフォルトのままにすることをお勧めします。

さらに、この記事は有益であることがわかりました： https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/

6
Isinlor