1

あいまいなタイトルを許してください、私はそれを説明する方法がわかりませんでした.

一般的なモデル「アーカイブ」がある場合、ユーザーが選択した「タイプ」に基づいてさまざまなビュー/フォームをどのように表示しますか?

たとえば、ユーザーは新しい「アーカイブ」を作成し、ビデオ、本、オーディオなどの選択肢を取得します。そこから、アーカイブの種類に基づいてさまざまな形式を取得します。

それとも、ビデオ、ブック、オーディオなどの異なるモデルに分割したほうがよいでしょうか?

または、モデルを継承できます (ビデオがアーカイブを拡張するように)。これは基本的な OOP / クラスだと思いますが、ここでそれを適用する方法がわかりません。

任意の MVC フレームワークからの例を歓迎します!

4

5 に答える 5

3

モデルのビデオ、ブック、オーディオはアーカイブから継承できます。

そして、各モデルにはコントローラーがあります。

http：// yourserver / Books / Edit / 11

対応するモデルを作成する前に、ユーザーに必要なアーカイブのタイプを選択させる必要があります。

編集（コメントに応じて）

ASP.NET MVCでは、モデルはクラスになります。

public class Video : Archive
{  
    public int Id {get;set}
    public string Name {get;set;}     
    ...
}

コントローラーもあります

public class VideoController : Controller
{
    public object Edit(int id)
    {
        Video myVideo = GetVideo(id);
        return View("Edit", myVideo);
    }
     ...
}

そして、たとえば、Viewsディレクトリにビューがあります。

public class Edit : View<Video>
{
    ...
}

したがって、次のようなURLがある場合は、これを呼び出すことができます。

http：// localhost / Video / Edit / 11

これはすべてメモリから行われたため、いくつかの間違いがあるかもしれませんが、持ち帰りのメッセージは、モデルで継承を指定することです。モデルは単なるクラスです。あなたの場合、あなたはアーカイブから継承したいと思います。これが完了すると、モデルは通常どおりパスアラウンドされます。

于 2008-09-24T19:23:59.570 に答える
3

タイプをアーカイブから継承させたくないようです。「継承よりもカプセル化/封じ込めを常に優先する」.

Archive というクラスを作成し、type プロパティを与えてみませんか。タイプは継承を使用して、オーディオ、ビデオなどに特化できます。

他の基準に基づいてアーカイブを専門化するように思われます。「FileSystemArchivce」、「XMLArchive」、「SQLArchive」およびタイプは変更されません。しかし、私のアジリストは、これは最初は必要ないかもしれないと言い、後でいつでもデザインをリファクタリングできます...

コントローラーに関しては、ビュー内の各タイプのプレゼンテーションの違いをカプセル化することで、おそらく最大の費用対効果が得られます。したがって、タイプに基づいてビューのみが変更されます。それぞれのセマンティクスとルールは同じである可能性が高く、タイプごとに個別のコントローラーを用意する必要はありません。属性が異なるため、ビューはタイプごとに異なります。

于 2008-09-24T19:40:59.607 に答える
3

実際に別のビューを表示することは、どの MVC フレームワークでも簡単なはずです。たとえば、Microsoft ASP.NET MVC では、次のようなコントローラーからビューを返すだけではありません。

return View();

ただし、実際にはビューの名前をパラメーターとして指定します。

return View("VideoArchive");

Views/Archive/VideoArchive.aspx からのビューが表示されます。

于 2008-09-24T19:31:42.903 に答える
1

単一責任の原則(PDF) は、次のように述べています。

クラスを変更する理由は 1 つ以上であってはなりません。

Archive クラスは、複数の異なるタイプのアーカイブを処理することにより、この原則に違反しています。たとえば、ビデオ アーカイブを更新する必要がある場合は、ブックとオーディオのアーカイブを処理するクラスも変更します。

これを処理する適切な方法は、異なるタイプのアーカイブごとに個別のクラスを作成することです。これらのタイプは、特定のアーカイブ タイプではなく、アーカイブのみを対象とするコードによって互換的に (ポリモーフィックに) 処理できるように、共通のインターフェイスを実装する (または共通の基本クラスを継承する) 必要があります。

クラス階層が整ったら、モデル クラスごとに 1 つのコントローラーとビューだけが必要です。

ボーナス ポイントとして、Single Responsibility Principle は、ファクトリ メソッドまたは抽象ファクトリを使用してモデル、ビュー、およびコントローラ オブジェクトを作成することを正当化することさえできます (インラインで新しく作成するのではなく)。結局のところ、オブジェクトを作成することとそのオブジェクトを使用することは別の責任であり、さまざまな理由で変更が必要になる場合があります。

于 2008-09-25T05:28:29.803 に答える
0

MVC を支持する確かな点の 1 つは、ユーザーが必要とするすべてが別のビューである場合、モデル (または 1 つだけが必要なコントローラー) をカスタマイズする必要がない可能性があることです。複数のモデルが登場するのは、ストレージ (持続性) アーキテクチャがその必要性を示した場合のみです。複数のモデルが必要な場合、データ アクセス オブジェクト (DAO) などの一部の機能は、コントローラーとモデルの間の別の層として表示される可能性があります。

例として、 Apache Strutsプロジェクトを見てください。Struts for Newbiesで述べられているように、「Struts を上手に使用するには、基礎を十分に理解することが重要です。まずKey Technologies の入門書を確認し、なじみのないトピックを調べてください。」

別のリソースについては、「Web 層アプリケーション フレームワークの設計(Sun J2EE ブループリント) 」を参照してください。

于 2008-09-24T19:31:36.040 に答える