4

私は春にMVCパターンに従ってWebアプリケーションに取り組んでおり、堅実なサービスレイヤーを作成するための「ベストプラクティス」とは何を考えているのか疑問に思っていました. この質問の理由は、次の例の状況です。

ユーザー情報を編集するページが読み込まれます。このフォームが送信された後、次のアクション (ユーザーの更新) に必要なデータのみを含む特定の Command クラスのコントローラー メソッドですべてのデータを収集します。

この情報をサービス層に渡すには、いくつかの状況が考えられます。

  • コマンド自体を渡す: userService.save(command);
  • コントローラーでフェッチされたモデル クラスを渡す: userService.save(user);
  • モデル クラスとコマンドの両方を渡す: userService.save(user, command);
  • すべてのパラメーターを個別に渡す: userService.save(command.getName(), ...)

私の意見では、コマンド クラス自体を渡すことは、最初にフレームワークを使用してすべての値を自動的に検証してからサービスに渡すことができるため、最も洗練されたソリューションのように見えます。ここでの懸念は、別のクラスからメソッドを呼び出すと (フォーム/コントローラーではなく)、このコマンド オブジェクトに無効なデータを入力して、サービス レイヤーでエラーが発生する可能性があることです。

何をお勧めしますか?その理由は?

4

4 に答える 4

1

あなたを見た後、私は次のアイデアを持っています。コマンド自体を渡す：userService.save（command）;

サービスレイヤーはコマンドオブジェクトに不必要に依存しているため、これは適切なアイデアではない可能性があります

Passing a model class, fetched in the controller: userService.save(user);

私はこれに投票します。サービスレイヤーは、実際に知っているはずのことだけをレイヤーします

Passing both a model class and the command: userService.save(user, command);

いいえ。最初のオプションと同じです

Passing all of the parameters individually: userService.save(command.getName(), ...)

うーん...わからない..将来的にはメンテナンスのオーバーヘッドになる可能性があります。

I think if you want to do the validation, Use validation util classes to do the validation 
    which can be used for both Service and UI layer. Here a lot validation can be centralized.
于 2013-02-08T11:30:45.867 に答える
0

Dino Esposito は、彼の MVC の本で、ビューモデルを受け取って返す「ワーカー」クラスを作成することを推奨しています。コントローラーはビューモデルを使用してワーカーを呼び出し、ワーカーは必要に応じてデリゲートします。実際には使用していませんが、理論的には優れたソリューションのようです。

于 2013-02-07T12:30:32.433 に答える
0

多層システムでコマンドを処理する場合に従うべき適切なパターンは、コマンドを特定のハンドラーにルーティングする CommandBus サービスを用意することです。そうすれば、コントローラーをサービスから切り離すことができます (汎用ルーティング システムと結合しながら)。

commandBus.handle(command);

コマンド バス ハンドラーを構成するには、追加の作業を行う必要がありますが、そのルーティング情報を再利用できるようになると、長期的には見返りが得られます。

commandBus.register(commandType, handlerService);

その後、サービス内のコマンドの検証を移動できる場合がありますcommandBus(ただし、これは、commandBus に関するいくつかの懸念事項が混在することを意味します)。

commandBus.registerValidator(commandType, validatorsCollection);

于 2013-02-08T22:00:11.767 に答える
0

Command オブジェクトを使用するオプションは、問題を引き起こします。疎結合を壊します。これで、サービス レイヤーがサービス レイヤーと緊密に結合されました。しないでください。

（編集：以下の私の回答では、プレゼンテーション層のモデルと言うとき、私はビューモデルについて話し、サービス層の場合はドメインモデルです）モデルオブジェクトを送信することは良いオプションのように見えます. ただし、モデルの作成方法によって異なります。場合によっては、プレゼンテーション レイヤーには異なるモデル構造が必要になり、サービス レイヤーには適度に/完全に異なる構造が必要になります。

両方のレイヤーのニーズが異なる場合は、2 つのモデル構造を作成する必要があります。このように、プレゼンテーション層が変更されたときにサービス層のモデル構造を変更する必要はありません。サービスには複数のコンシューマがあり、プレゼンテーション層が変更されたときに変更できない可能性があるため、これは重要です。

それらが異なる構造を持っていない場合でも、ここではサービスが実際の再利用可能なコンポーネントであるため、サービス層の観点からそれらを作成します。

于 2013-02-08T21:35:53.670 に答える