MVC ではモデルはどのように構造化されるべきですか?

MVC では、モデルはアプリケーションのビジネス ロジックとデータを表します。ドメイン固有のロジックとルールをカプセル化し、アプリケーションが UI やコントローラーに依存せずにタスクを実行し、意思決定を行えるようにします。

モデルの概念:

• ]

  モデルはクラスやオブジェクトではありません。これは 3 つの主要な要素で構成されるレイヤーです。

  • ドメイン オブジェクト: ビジネス エンティティを表し、問題ドメインに固有のロジックが含まれています。
  • データ マッパー: データの永続性と外部ストレージとの対話を処理します。
  • サービス: ドメイン オブジェクトとデータ マッパー間の対話を調整し、ビジネスと対話するためのより高いレベルのインターフェイスを提供します。ロジック.

関心事の分離:

• モデル層は UI 層 (ビューとコントローラー) から分離されています。 .
• モデルとの通信はサービスを通じてのみ行われ、懸念事項を明確に分離し、UI またはコントローラーへのドメイン ロジックの漏洩を防ぎます。 code.
• この分離により、単一責任原則 (SRP)、柔軟性、テスト容易性が促進されます。

モデルへのアクセス:

• ビューとコントローラーでは、Symfony の DI コンテナーやAuryn.
• サービスはコンストラクターに挿入したり、ファクトリを通じてアクセスしたりできます。
• このアプローチにより、必要なすべてのサービスがこれらのコンポーネントで利用できるようになります。

モデルの状態の変更:

• コントローラーはユーザー入力の処理とモデルの変更を担当します。 state.
• これらはサービス メソッドを呼び出し、次にドメイン オブジェクトおよびデータ マッパーと対話して必要な論理操作を実行します。

Data Persistence:

• ドメイン オブジェクトはビジネス エンティティを表しますが、ストレージは認識しません。
• データ マッパーはデータの永続性を処理し、外部ストレージからの取得。
• この分離により、ビジネス ロジックは使用される特定のストレージ テクノロジから独立したままになります。

分離の利点:

]
• 各レイヤーに明確な責任を割り当てることで SRP を適用します。
• ビジネスを分離することでコードの可読性とテスト容易性を向上させます。ロジック。
• 他のコンポーネントに影響を与えることなく、ビジネス ロジックやデータ ストレージを柔軟に変更できます。
• モデル サービスにアクセスするための一貫したインターフェイスを提供することで、外部 API の開発を簡素化します。

追加コメント:

• データベース テーブルは、必ずしもドメイン オブジェクトおよびデータに直接マップされるわけではありませんマッパー。
• ビューはテンプレートではありませんが、プレゼンテーション ロジックとテンプレートの選択を処理します。
• 各ページまたは画面のビューとコントローラーの間には 1:1 の関係がある必要があります。