Help us understand the problem. What is going on with this article?

Symfony Best Practicesを読んで感じたこと

More than 5 years have passed since last update.

Symfony Best Practicesを読んで、「なるほどなぁ」と感じたり、「えー!?」と感じたりがいくつかあったので、自分なりの感想をまとめてみました。

作成にあたり、日本語訳には大変お世話になりました。翻訳者の方々、ありがとうございます。

The Symfony Framework Best Practices

Keep in mind that these are optional recommendations that you and your team may or may not follow to develop Symfony applications.

you should not refactor your existing applications to comply with these best practices.

まず最初に、ベストプラクティスとはの説明です。recommendationsというのが重要で、mustではありません。
既存のアプリケーションをリファクタリングすべきでもありません。
ただ、"Best Practices"を読む前と後では、少なからずアプリケーションの設計・実装方針が変わってくることでしょう。

Creating the Project

Create only one bundle called AppBundle for your application logic

アプリケーションのバンドルは"AppBundle"ひとつにしましょう、ですか!
ユーザー登録画面など、機能ごとにバンドルにした経験があります。

But a bundle is meant to be something that can be reused as a stand-alone piece of software.

バンドルは単体で再利用できるものですよ、と。この方針を意識していればバンドルを乱立せずに済みそうです。

Configuration

Define all your application's parameters in the app/config/parameters.yml.dist file.

アプリケーションのふるまいに関係ないパラメータはapp/config/parameters.yml.distに記述しましょう、とあります。
symfony2.3のデフォルトでは、データベースの接続設定、メールサーバの接続設定、ロケール、シークレットが記載されています。
parameters.yml.distにあってparameters.ymlにないパラメータはsymfonyがプロンプトを出して設定を促します。
なので、parameters.ymlはバージョン管理外にしてparameters.yml.distを管理するのがsymfonyの流儀になります。

Define the application behavior related configuration options in theapp/config/config.yml file.

アプリケーションのふるまいに関する設定はapp/config/config.ymlに定義しましょう。
私は以前バンドルを乱立させたアプリケーションを作ったがために、config.ymlがバンドル内にあったり、app/configにあったりと、自ら見通しを悪くさせていました。

AppBundle + app/config/config.ymlで、どんな設定があるのかの見通しがよくなるでしょう。

Use constants to define configuration options that rarely change.

めったに変わらない設定は定数を使いましょう。これは自然とできているかなぁ。例のようにnum_itemsを10に設定しようと思いません。ただ、constを書くファイルは気にしています。クラス内の閉じている定数であればクラス内、共通で使用するような定数は専用のクラスを作ってその中でconst定義をしています。

Organizing Your Business Logic

Use the YAML format to define your own services.

はい。サービス名に限らず設定はすべてyamlを選んでいます。xmlはパッと見がわかりづらいです。

Don't define parameters for the classes of your services.

クラス名をパラメータとして別定義するなと。たしかに、クラス名の定義をパラメータから探して…は、効率が悪いです。私は過去に、複数のクラスが名前空間が共通のために、名前空間をパラメータ定義したことがあります。これも推奨されないのでしょうね。サービス定義には、名前空間含めてパラメータを使わないクラスそのままを使用する。

Controllers

Make your controller extend the FrameworkBundle base Controller and use annotations to configure routing, caching and security whenever possible.

ルーティングの設定はアノテーションを使いましょう、と。私はパラメータとして別ファイルでまとめて管理していたのですが、クラスを見るだけでルーティングがわかるのは見通しがいいかもしれません。一覧が見たければコマンドがありますからね。

Templates

Use Twig templating format for your templates.

はい。Twig以外考えられません。

Store all your application's templates in app/Resources/views/ directory.

バンドル以下じゃないのですね。たしかにapp以下であればテンプレートを指定する際にバンドル名を指定する必要がありません。これもアプリケーションをAppBundleのみにする方針と連動していますね。

Forms

symfonyのフォームは強力です。自前でタグを書くことがないよう、ドキュメントで説明されている流儀に従いましょう。

さいごに

以上、ざっと書いてきましたがsymfonyを使っていて感じることは、柔軟性もさることながら流儀に乗っていると感じているときの開発効率の高さです。

逆に、「なにかややこしいことになってきたなぁ」と感じるときは、たいていsymfonyの流儀に逆らっています。
難しくなる前に一度踏みとどまって、シンプルに流儀に乗ることがsymfonyで快適に開発するコツだと思っています。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした