7

最も単純なASP.NETMVC2コントローラーは、サービスレイヤーを呼び出し、AutoMapperを使用してビューモデルをエンティティにマップします。すべてが素晴らしく見え、繰り返されるコードはありません。

ただし、同様の動作をするシナリオに入ると、単一責任原則（SRP）とDo n't Repeat Yourself（DRY）のバランスを取るのに問題があります。この例としては、一部のプロパティ/動作が共有され、他のプロパティ/動作が特定の車両に固有である車両を追加/編集する必要がある場合があります。

本当に薄いコントローラーを目指して（したがって、単一責任の原則を尊重して）、ビューとコントローラーの両方で、わずかなバリエーション（タイトル、フィールドラベル、フィールドの可視性、ドロップダウン値、選択基準など）でコードを繰り返すことになります。

繰り返されないコードを目指して努力すると、ロジックを1つのコントローラー/ビューにバンドルしすぎて、肥大化してしまいます。

コントローラ/ビューで繰り返されるコードに対処するいくつかの方法は何ですか？リポジトリに分解できるデータベースコードについては話していません。また、サービス層に分解できるビジネスロジックについても話していません。上記のシナリオで最適なソリューションを作成するのに役立つツールや経験則を探しています。

4

4 に答える 4

3

あなたが得る：

  • パーシャル
  • RenderAction
  • アクションフィルター
  • サービスレイヤーとヘルパークラス（HtmlHelperではない）
  • モデルバインダー
  • ベースコントローラー
  • 依存性注入

そのため、ビューで同様のパーツの共有パーシャル/アクションを呼び出したり、アクションフィルターで共通データを準備したり、データベースアクセスコードをスマートモデルバインダーで非表示にしたり、子コントローラーが特定の調整でオーバーライドする親コントローラーを使用したりできます。そしてもちろん、古き良きサービスレイヤーでは、一般的なコードをヘルパー/静的メソッドに抽出するか、より適切には特定の実装を注入します。

それは新しいものではなく、同じ古いトリックです。

または、多分、あなたのコントローラーはあまりにも多くの仕事をしますか？これは、上記のものも役立つところです。ASP.NET MVCには、インフラストラクチャレイヤーコードを非表示にしてコントローラーから移動するための非常に優れたツールがあります。そして、それがインフラストラクチャではない場合、おそらくドメイン層に属しています。そこでは、継承、構成、およびその他のOOPトリックを使用できます。

具体例。コントローラが別の方法でいくつかのプロパティを設定する必要があるとします。

  1. ほとんどがフォーマットされているか、表示するプロパティを選択している場合は、これを行うためのビューを持つことができます
  2. エンティティに仮想メソッドを持たせることができます。つまり、コードをリファクタリングして、決定をコントローラーではなくドメインレイヤーに移動します。
  3. エンティティを取得し、必要なものに基づいてデータを取得するヘルパーViewDetailsクラスを作成できます。これは少し汚いトリックですが、時々役に立ちます。決定を別の「戦略」クラスに委任します
  4. アクションフィルターを使用して、このデータをViewDataに追加したり、特定のViewData.Modelタイプを微調整したりできます（そのインターフェイスを探します）。
  5. 子が実装の詳細を（）のようにベースコンストラクターに渡す抽象コントローラーを持つことができます：base（repository => repository.GetSpecificData（））

等々。私は実際にそれらすべてを適切な場所で使用しています。

于 2010-11-12T20:47:02.870 に答える
0

あなたはSRPとDRYについてあまり心配しています。それらは原則に過ぎず、常に正しいとは限りません。SRPとDRYは、コードをより保守しやすくする場合に適していますが、邪魔になる場合は無視してください。MVCも同様です。単純な小さなデスクトップアプリケーションでは便利ですが、Webアプリケーションには適していません。Webフォームはインターネットの世界にとってはるかに優れていますが、MVCは1980年代のものです。

于 2010-11-16T03:22:39.453 に答える
0

そのような場合は、SRPoverDRYを使用することをお勧めします。私はここに詳細な答えを書きました。

つまり、どちらもコードを保守しやすくするためのルールです。DRYは抽象化レベルの低いメカニズムですが、SRPは抽象化レベルの高いメカニズムです。アプリケーションを維持することにより、高抽象化レベルの構造が低抽象化レベルよりも重要になります。

あなたの場合、DRYをあきらめる必要はないと思います。

この例としては、一部のプロパティ/動作が共有され、他のプロパティ/動作が特定の車両に固有である車両を追加/編集する必要がある場合があります。

この場合、多くのデザインパターンが役立ちます。デコレータ、コンポジションなどをさまざまなタイプの車両用のビルダーと組み合わせて使用​​できます。

于 2014-05-25T03:13:23.713 に答える
0

ApiEndpointsがこれに非常に適していることがわかりました。コントローラメソッドごとにクラスを作成します。もう少しコードですが、とてもきれいだと思います。

于 2021-04-14T04:41:32.587 に答える