3

先週の仕事で、私たちはMVCのやり方を再考することについての会議/プレゼンテーションを行いました。これは、おそらく上司による多くの調査と他のSOの質問へのいくつかの読みに基づいています。私にとっての1つのポイントは、人々が「データからロジックを分離する」と言うとき、「データソースからロジックを分離する」と言う方がおそらく正確だということでした。最初に行うと、貧血ドメインモデルの餌食になる可能性があります。私はこれで正しいですか？

次に、MVCにはビジネスロジックがどこにも含まれていないことを学びました。これは、Webアプリとは別のサービスレイヤーまたはBLLにある必要があります。これらの2つのポイントを調整するのは少し難しいようです。基本的なOOPの原則で示されているように、特定のロジックはデータオブジェクトに対応していますか、それとも別のレイヤーにありますか？

これが私が今助けを必要としている特定の例です。これはサービスレイヤーに属するとかなり確信していますが、他にも質問があります。異なるタイプの複数の異なるエンティティを入力として受け取る動作があるとしましょう。実行され、出力として、入力エンティティを変更し、レコードとして新しいエンティティを生成できます。私の場合はゲーム用ですが、トランザクションのようなものと言えます。複数の人が関わっており、一部の製品と領収書が生成されています。

  1. 簡単な質問ですが、このロジックをどこに配置しますか？インスタンス化されるのは別のクラスですか？
  2. （私にとって）難しい質問は、このコードを呼び出す責任があるのは誰ですか？コントローラーにそれをさせるのは間違っていると感じるでしょう。それともまさにその仕事ですか？特定のページで実行されないが、ユーザーが特定の時間後にサイトにアクセスするたびに実行される場合はどうなりますか？ベースコントローラー？
  3. 一般に、「これは私のエンティティクラスに属しているため、ゲッターとセッターの山だけではありません」と「これは私のサービスレイヤーに属します」のどちらを選択しますか？それとも私は物事を混同しています...エンティティクラスはサービスレイヤーに属していますか？
4

1 に答える 1

4

まず、いくつかの用語を整理しましょう。あなたが「サービスレイヤー」と呼んでいるものは、あなたが言うように、MVCモデルと混同しないように、より一般的に「ドメインモデル」と呼ばれています。最も基本的なレベルでは、MVCモデルはドメインモデルをカプセル化します。2つの相互作用の方法はパターン自体では定義されませんが、モデルストアの状態は、2つの異なる状態があることを論理的に理解することです。

  • ドメインの状態-現実の世界では、これはデータベースに何らかの形で保存されることがほとんどですが、ドメインモデルはデータソースをMVCモデルに公開するべきではありません。これにより、ドメインモデルは適切なカプセル化を保持できます。このデータを変更またはアクセスするロジックは、MVCモデルがアクセスするための関連する抽象アクセサーを使用してここで実行する必要があります。

  • アプリケーションの状態-「現在、どのレコードが編集されていますか？」などです。

あなたの質問に答えるために、それはあなたがデータで何をしているかに本当に依存します。何らかの処理を行う場合は、ドメインモデルで行う必要があります。表示目的で必要なデータのコレクションをフェッチするだけの場合、MVCモデルはドメインモデルにクエリを実行して、関連するデータを取得する必要があります。次に、ビューはこのデータのモデルを照会する必要があります。

だからあなたの質問に答えるために：

  1. この特定のケースの場合：データを処理するトランザクションは、ドメインモデル内にある必要があります。関連するすべてのデータに直接アクセスできるため、必要なパラメーターを指定して呼び出す必要があります。これは、MVCモデルに直接関連付けられていないため、再利用性を促進します。
  2. 技術的には、コントローラーがドメインモデルに直接アクセスしている場合、MVC実装よりもMVVM実装に近くなります。ただし、ドメインモデルがドメインロジックに関連付けられていない引数を取る場合、これは悪いことではありません。実際の問題はありません。ただし、コントローラーはドメインオブジェクトを構築するべきではありません（たとえば、ユーザーアカウントを作成し、それをモデルに渡す）。MVCトライアドの外側にあるドメインモデルを使用する理由は、まさにそのためです。コードを何と呼ぶか​​は問題ではないため、ドメインロジックは、実行されているアーキテクチャに依存しません。これは良いことです。MVCは現在のものであり、ドメインロジックが単なるデータ処理である場合もあります。「ユーザーが特定の時間の後にサイトにアクセスするときはいつでも」これはドメインロジックであるため、ドメインモデルに確実に組み込む必要があります。
  3. それはそう。エンティティ（単一のドメインオブジェクト、ユーザー、製品、ブログなどを参照するオブジェクトを意味すると想定しています）は、ほとんどがデータ構造であるため、おそらくそれ自体には多くのロジックが含まれていません。注文には、関連するエンティティをフェッチする「getProducts（）」または「getDeliveryAddress（）」が含まれる場合がありますが、ドメインモデルはデータ自体に対して任意の処理を行います。

経験則として、データを変更したり、複数のエンティティからのデータを処理したりするほとんどすべてのロジックは、ドメインモデルで発生する必要があります。これには2つの主な理由があります。1。再利用性、そのロジックはどこからでも再利用できます。2.カプセル化。このロジックをエンティティ内に配置し始めると、ドメインエンティティが他のドメインエンティティに依存している状況になります。これにより、「これらの顧客は支払いの詳細を入力する必要がない」など、後日任意のルールが導入されることになり、現実の世界では非常に脆弱なコードになります。「注文」をモデル化した場合、「これは法人顧客であり、請求先住所はありません」

于 2012-12-10T23:48:01.940 に答える