0

インターネットで調べてみると、ロジックは入れるべきだという人もいれば、アプリケーションViewModelに入れるべきだという人もいます。Controllerasp.net with mvc

なので結論は出せません。

  1. これに対する公式（MVCを使用したasp.netの作成者）の推奨事項は何ですか?
  2. それを決める理由は何ですか？(explanationsとexamples) ?
4

2 に答える 2

0

ビュー モデルには、プレゼンテーションに関連するロジックのみを含める必要があります。間違いなくビジネスロジックはありません。

ビジネスロジックも実際にはコントローラーに入るべきではありません。コントローラーは、要求に応じて採用されるコンポーネントのコーディネーターでなければなりません。

最も単純なアプリケーションを除いて、ビジネス ロジックを実装し、モデルを操作/保持するサービス層を作成する必要があります。

大規模なアプリケーションの場合、サービス レイヤーからアクセスされる専用のビジネス ドメイン レイヤーを使用することもできます。

MVC (およびその他の) アプリケーションでドメイン/ルール/ワークフローを実装し、同じ場所に配置するのに役立つライブラリがあります。ここです。

于 2013-03-27T09:39:47.117 に答える
0

現在、ソースまたは参照を提供することはできませんが (要件に従って)、ビジネス ロジックはコントローラーのアクション メソッド、またはアクション メソッドによって呼び出される別のレイヤー (ASP.NET MVC の場合はバックエンド Web サービスなど) に配置する必要があります。アプリケーションは、Exchange Server に対する OWA と同様に、既存のアプリケーションのフロントエンドとしてのみ機能します)。

この正当化の中心にあるのは「懸念」の概念です。この場合、ViewModel オブジェクトは、View と Controller('s Actions) の間のデータの転送と検証 (ただし、検証ではない) のみに関係する必要があります。ASP.NET MVC では、ViewModel クラスは、ビュー内のユーザー提供データに対応するプロパティだけで構成される POCO (Plain Old CLR Object) である必要があります。私自身のプロジェクトでは、これを拡張して、コントローラーのアクションにプロパティを直接入力するのではなく、ビジネス エンティティから ViewModel オブジェクトにデータを変換するようにしています。MVC のパイプラインに加えた変更を使用して、独自の検証ロジックも実行します。

于 2013-03-27T08:14:39.013 に答える