3

MVCまたは一般的に、ビューからビジネスロジックを分離しようとする場合、ビューからロジックを削除するという点で、どこまで進んでいますか？ビューのロジックはゼロにする必要がありますか？変数が埋める単純な「穴」を持つ複数の静的ビューがあるべきですか、それとも状況に応じて異なるhtmlを出力できる単一のビューを持つことができますか？

<html>
    <body>
        <h1>Your name is @uname</h1>
        @if(account<3000) { 
             <p>You are an ok customer</p>
        } else { 
             <p>You are a great customer</p>
        }
    </body>
</html>

上記はOKですか、それとも2つのビューが必要ですか。1つはOKの顧客用で、もう1つは優れた顧客用です。

4

4 に答える 4

0

私の意見では、余分なビューを持つことは、多くの場合、htmlコードを複製することにつながるため、間違っているでしょう。

あなたが提供したサンプルif..elseでは、​​ビュー内でブロックを使用することに固執しますが<p>、最終的には1つだけにし、そのテキストを変数に設定します。何かのようなもの

 @string text = account<3000? "you are ok":"you are great";             
 <p>@text</p>

もちろん、別の解決策もありTypeOfCustomerます。この関連するテキストを使用して、文字列プロパティを持つViewModelクラスを使用してモデルを拡張します。

要約すると、正しいhtmlを設定するために、その「違法」がビューにそのようなブロックを持っているとは思いません。ケース間の差異が共有コードよりも小さい限り、ブロックを含む1つのビューを持っていても問題はありませんif..else。

于 2012-10-12T12:53:15.533 に答える
0

従来のMVC実装では、ビューにプレゼンテーションロジックが含まれます。MVCデザインパターンは、モデル層とプレゼンテーション層の2つの層で構成されています。ビューとコントローラーはプレゼンテーション層を最大限に活用し、コントローラーがユーザーインタラクションを処理し、ビューがユーザーインターフェイスを処理します。

Webアプリケーションに従来のMVCパターンを実装することは実際にはできません（実際にはできますが、実際には不可能です）。ASP.NETMVCフレームワークでは、通常、これにアプローチする2つの方法があります。

  • Railsのようなもの：プレゼンテーションロジックをコントローラーにプッシュし、ほとんどロジックのないテンプレートを残します。しかし、レールの実装に問題があるため、これは悪い選択だと思います。

  • ViewModels。この構造により、コントローラーとは別にプレゼンテーションロジックを含めることができます。ASP.NET MVCドキュメントで説明されているように、ViewModelsは実際には従来のビューである必要があるため、実際には少し誤った名前が付けられています。プレゼンテーションロジックをViewModelインスタンスに配置し、「ビュー」をテンプレートとして使用します。これにより、可能な限り小さなプレゼンテーションロジックを含めることができます。

于 2012-10-12T12:54:59.123 に答える
0

技術スタックに関係なく、基本的にあなたが言っていることは、アカウントが 3000 未満であれば顧客は優れているということです。

したがって、Customer State(これをより適切な言葉に置き換えてくださいAccountState?) はGoodまたはのいずれかになりますGreat。

したがってState、 は のファセットでCustomerあり、 のプロパティ/メソッドである必要がありますCustomer。

于 2012-10-12T13:03:15.207 に答える