一般に、私はこれらまたはシステムに実装したいソリューションを設計、熟考、分析するのが好きです（ただし、私はこれにはほとんど経験がありませんが）、あなたが考えて1日過ごしたことを顧客に説明する方法...えー...
気が散ります 今日は、Symfonyを使用してシステムを開発する際の開始点と、従うべきルールについてお話したいと思います。
実際、すべてはプロジェクト（プロジェクト）とその中のアプリケーション（アプリケーション）の作成から始まります。 これがどのように行われるかは本で読むことができます（上記のリンクを参照）が、プロジェクトとは何か、プロジェクト内のアプリケーションを選択するための原則-彼らが与えるべき名前、それらを構成する方法などについて説明したいと思います。
プロジェクト
私が理解しているように、一般的な場合、サイト全体に1つのプロジェクトがあり、このプロジェクトのすべてのアプリケーションが使用するアプリケーション、構成ファイル、およびモデルの一種のリポジトリになると想定されています。
用途
Djangoとは異なり、ここではアプリケーションは他のプロジェクトで使用できるシステムの原子単位ではありません... Symfonyでは、プロジェクトの機能を論理的に（物理的に）区別するためにのみ作成されました。 そして最も重要なこと-アプリケーションは、1つのプロジェクトのフレームワーク内にのみ存在する場所を持っています。 つまり プロジェクト内の1つのアプリケーションを削除しても、他のアプリケーションは影響を受けませんが、プロジェクトの設定やプロジェクトモデルなどに依存するため、あるプロジェクトから別のアプリケーションへの転送には非常に問題があります。
プロジェクトでフロントエンドとバックエンドの2つのアプリケーションを作成することが公式に推奨されている（「提案済み」と読む）と言うと便利です（ロシア語を話す視聴者にとっては、この場合の「管理者」という用語の方が適切です）。 私自身は、1つの目標を設定するモジュールを組み合わせるためだけにアプリケーションを作成することをお勧めします。 たとえば、同じ管理パネル、ユーザーインターフェイス（たとえば、ユーザープロファイル、ユーザーがサイトで変更できるすべてのもの）、フロントエンド（すべてのユーザーがアクセスできるすべてのもの）。
私自身は本の推奨事項を使用し、私のプロジェクトには2つのアプリケーションがあります。
このアプローチの長所と短所を検討したくありません。 私にとっては、Djangoのアプローチのほうがはるかに便利で論理的であり、初心者向けのこれらのプロジェクト/アプリケーションはかなり複雑で理解しにくいとしか言えません。 特にSymfonyのプラグインは基本的に同じDjangoアプリであると考えていますが、それについては後ほど説明します。
環境
私は特に周囲に住みたいとは思いません。 これは非常に便利ですが、同時に非常に単純なメカニズムであり、異なるサーバー設定で同じアプリケーションにログインする機能を提供します。 簡単に言えば、アプリケーションと、動作モードをデバッグモードに、またはその逆に切り替えるチェックマークがあると想像してください。 たとえば、デバッグモードでは、すべてのイベントが記録され、すべてのエラーが画面に表示されます。 デバッグモードがオフになっている場合、すべてのログがオフになり、画面にエラーが表示されなくなります。 そのため、Symfonyでは、デバッグ/
一般的に、文句を言う必要はありません-私の意見では、すべてが完璧です。
モジュール
...アクションとビュー（ MVCの MVなど）を備えたコントローラー、およびこの特定のモジュールでのみ必要な構成ファイルと、場合によってはライブラリーが含まれます。 ここではすべてが非常にシンプルで明確です。
モジュール（プロジェクトを備えたアプリケーションなど）は自動的に作成できます（コマンドラインを使用）。 単純なモジュールの作成に加えて、テーブルの1つ、または管理パネル（再び、テーブルの1つ）に対して（再び-自動的に） CRUD （ スキャフォールディング ）を作成できます。 管理パネルは、コードを実際に書く必要がないという点で異なります-その中のほとんどすべて（フィルタリング、ソートなど）は、非常に便利な設定ファイルを使用して設定されます（ジャングラーにとってはこんにちは、彼らは理解します）。 CRUDは、開発の初期段階で非常に役立ちます。 例-ユーザーテーブルを追加したので、次を行う必要があります。ユーザーのリストを表示し、ユーザーにプロファイルの編集と登録を許可します。 最初からすべてを作成する代わりに、ユーザーテーブル用のCRUDモジュールを作成します。その後、既に生成されたコードに基づいて独自のコードの作成を開始できます。 このようなソリューションの暗黙的な利点は、モジュールのコードが互いに類似して取得され、混乱が少ないことです。
最後に説明したいのは...
モデル
すべてのモデルは、1つ（または複数）のYAMLファイルに保存されます。
多分これは、Symfonyを勉強するときに初心者が必要とするかもしれないことのすべてです（そのため、1年前に私に思われた、
そして今、私たちの推奨事項に直接進みます。 しかし、その前に私はあなたについて教えます...
プラグイン
プラグインは、実際には、さまざまなプロジェクトやアプリケーションで何度も使用できるコードです。 プラグインには以下が含まれます。
- モデルを含む構成ファイル（!!!）
- モジュール
- 図書館
私は間違っているかもしれませんが、プラグインはそのようなミニプロジェクトであり、Symfonyアプリケーションと比較して「すべてがそれ自体」であるように思えます。 私の意見では、賭けは主にそれらに行われるべきです-アプリケーションを削除し、代わりにプラグインをインストールし、これらのプラグインが相互に通信できるようにする何らかのツールを作成します。
私の推薦
- まず第一に-デザイン。 このステップをスキップして、顧客との不可解な点を分析して明確にしないでください。
- システムのレイアウトを目の前で（はい、あなたの頭の中でも）見ます-システムのどの部分を分割できるかを考えます。
- 既存のプラグインの中からそのような部分を探してください（ 必須 ）。 プロジェクトで次のプラグインを使用しました。
- sfGuardPlugin-ユーザー管理、セキュリティなど プラグイン-が必要です。
- sfDateTimePlugin-日付と時刻を扱う非常に便利な作業
- sfPropelAlternativeSchemaPlugin-プラグインを使用する場合に便利で、プラグイン自体のコードを変更せずにプラグインで指定されたモデルを変更できます
- sfPropelApprovableBehaviorPlugin- 「ユーザーのアクティベーション」 時に非常に役立ちました
- sfThumbnailPlugin-画像の縮小（名前を見ないでください-3MP
写真 を800×600にリサイズすると、プラグインは完全にうまく対処します） - sfPropelActAsTaggableBehaviorPlugin-タグが必要な場合
- sfPropelActAsSluggableBehaviorPlugin-ナメクジが必要な場合（およびそれらを使用することをお勧めします-idの代わりにナメクジを配置すると、URLの可読性に非常に良い効果があります）
- sfPropelActAsRatableBehaviorPlugin-評価は非常にクールですが、残念ながら私には合いませんでした...
- sfPropelActAsCommentableBehaviorPlugin-コメントに必要なものすべて
- 自動生成されたCRUDモジュールと管理パネル用のモジュールを使用する
関連リンク
- Symfony 1.1フォームフレームワークに関する一連の素晴らしい投稿
- Symfonyブログ
- ロシア語を話すSymfonyのコミュニティ （私の意見では、もしあなたの英語が多かれ少なかれ普通なら、ここにはまったく行かないほうがいいでしょう）。
- ロシア語のsymfonyの本はここで読むのが最適です （私が理解しているように、いくつかの翻訳があり、そのうちの1つは上記のサイトにありますが、ここに最も完全です）。
今日はこれでおそらくすべてです。 あなたのコメントを待っています。
私のブログのクロスポスト。