DRY 原則と、ASP.NET MVC での DRY 原則の重要性についてよく耳にしますが、Google で調査を行っても、DRY 原則が MVC にどのように適用されるかを正確に理解していないようです。
私が読んだことから、実際にはコピー＆ペーストコードの匂いではないと思っていましたが、それ以上のものです。
ASP.NET MVC アプリケーションで DRY 原則をどのように使用するかについて、洞察を与えることができる人はいますか?
4536 次
8 に答える
7
DRY は「Don't Repeat Yourself」という意味です。コードを記述するときは、一度だけ記述してください。すべての Controller クラスで同様の機能を記述している場合は、その機能を持つ基本コントローラー クラスを作成してから継承するか、すべてのコントローラーで同じ機能を繰り返すのではなく、その機能を別のクラスに移動してそこから呼び出します。
于 2008-10-09T16:05:13.900 に答える
4
- フィルタ属性を使用してアスペクト（認証、ナビゲーション、ブレッドクラムなど）を管理します
- レイヤースーパータイプコントローラーを使用します（一般的なコントローラーレベルのフィルターを適用します。例については、mvccontribを参照してください） 。
- カスタムactionresultsを記述します（mvccontribのように-たとえば、logoutresultと呼ばれるものを作成しました。
FormsAuthentication.Logout() - ビュー名に規則を使用する
- 最も重要なこと-コントローラーのアクションを馬鹿にし、サービスで再利用の機会を探す
于 2008-10-12T17:47:39.513 に答える
2
繰り返さないでください。プログラミングのさまざまな側面に適用できます。これの最も基本的なレベルは、コードの臭いを防ぐことです。ASP.NETを使用したことがないため、ASP.NETとMVCに固有のものを取得できません。
- C ++では、テンプレートは同じ関数の複数のコピーを事前に作成します。
- Cのvoid*ポインターも同様の方法で使用できますが、細心の注意を払って使用できます。
- 別の関数から継承すると、他の関数がコードをコピーしなくても同じコードベースを使用できるようになります。
- データベース内のデータを正規化すると、冗長データが最小限に抑えられます。DRYの原則にも準拠しています。
プロジェクトの「思考」を検討するとき。自問してみてください。
- 私はすでにこのコードを書いていますか？
- このコードは他の場所で役立ちますか？
- 以前のクラス/関数から構築してコーディングを節約できますか？
于 2008-10-09T16:12:55.817 に答える
1
自分自身を繰り返さないことに関連する MVC の利点の 1 つは、コントローラーが 1 つのクラス内のすべてのページに共通のタスクを実行できることです。たとえば、特定の種類の悪意のある要求に対する検証や認証の検証を一元化できます。
于 2008-10-09T16:22:33.740 に答える
1
DRY は特定のテクノロジーに固有のものではありません。機能の観点から (コピー/貼り付けコーダーの観点からでも) クラスを見て、重複が発生する場所を確認してください。このプロセスはおそらく 1 回で完了することはなく、数か月後に新しい機能を追加するときにコードをレビューした後に重複に気付くだけです。単体テストがある場合は、その重複を削除することを恐れる必要はありません。
于 2008-10-09T16:09:35.077 に答える
0
DRYとUIについて説明できる最も一般的な例は、MasterPagesやUserControlsなどを使用することです。
MasterPagesは、すべての静的HTMLを1回だけ記述したことを確認します。
UserControlsは、コードの再利用性を保証します。たとえば、CRUDのような基本的なことを行うフォームがたくさんあります。理想的には、両方のフォームフィールドはほぼ同じですが、すべてのユーザーに[作成]と[更新]の異なるページを表示する必要があります。私たちにできることは、すべての共通のコントロールを組み合わせて、両方のページで再利用できるコントロールにそれらを配置することです。これにより、同じコードを再入力（またはコピー貼り付け）することがなくなります。
DRYは、同じタスクを実行するためのファイルの数が増えるため、MVCでは特に重要です。
于 2008-10-13T14:39:20.203 に答える
0
ドメイン モデル内のすべてを特別なビュー モデルとしてコピーする必要があるという誤解があるようです。ドメイン モデルをドメイン モデルにすることもできますが、ビュー モデルはドメイン固有のものを何も知らず、より一般的なものにすることができます。例えば：
ドメイン モデル クラス: Account、Asset、PurchaseOrder
ビュー モデル: リスト、テーブル、タプル、SearchFormBackingModel:Checked オプション、Outputoptions など。ビュー自体は、ビューの実装に固有のものである可能性があります。
Tuple/Dictonary/Map は、Account、Asset、PurchaseOrder の単一インスタンスにマップされる可能性がありますが、テーブルはそれらのコレクションなどに役立つ場合があります。MVC はまだありますが、セッション データがあり、ビュー モデルでトランザクションの準備ができていないため、必ずしもビュー モデルで処理する必要はありません。ルールが適用されるドメインモデルのルールに違反すること。そのようにして、貧血やアンチパターンが少なくなります。これらのルールを前もって渡して、システムがクライアントからどのように読み取るかなどに応じて、そこで使用することも、後ろで使用することも、その両方を使用することもできます。
于 2013-01-18T19:42:09.437 に答える
0
DRY はコードだけでなく、情報全般に適用する必要があります。ビルドシステムで繰り返していますか? 共通の構成ファイルなどに移動する必要があるデータはありますか?
于 2008-10-12T18:04:20.790 に答える