問題タブ [model-view-controller]

メンバーシップ セキュリティ ログイン ロールに基づいて、マスター ページにメニュー項目を動的に追加したいと考えています。私が読んだことから、マスターページhtmlのRenderActionはおそらくこれを行うことができます。私はこれを手探りしているので、それがどのように見えるのか、コントローラーで現在の役割をどのように確認するのかわかりません。テーブルを作成し、許容されるメニュー項目をロール関係に関連付けて、動的メニュー項目をレンダリングするためにマスター ページに渡すことができるようにすることを検討しています。

MVCを実装する前にMVC を適切に理解するための私の探求における 3 番目の質問:

私は2つのケースを念頭に置いています：

1. プライマリ アプリケーション ウィンドウは、設定ウィンドウを起動する必要があります。(あるビューが別のビューを呼び出します。)
2. アプリケーションのプライマリ モデルは、設定モデルのプロパティにアクセスする必要があります。(あるモデルが別のモデルにアクセスします。)

これらの質問は、どちらも Model-View-Controller トリプレット間の通信に関係しているという点で関連しています。これは、Google であまり議論されていないトピックです。

これを修正する明白な方法は、モデル間のトランザクションを処理し、コントローラーが互いのメソッドを呼び出せるようにする最上位の「アプリケーション」オブジェクトにすべてをラップすることです。私はこれが実装されているのを見てきましたが、それが良い考えだとは確信していません。コントローラーが複数のモデルを監視し、複数のビューに応答する可能性も見られますが、これは非常に雑然として追跡が困難になるようです。

この種のクロストークを実装する最善の方法についての提案はありますか? 非常に明白な質問のように感じますが、十分に文書化された解決策を見つけることができませんでした。

より広い意味で、この種の MVC の問題に対する典型的なアプローチを示すリンクを誰かが持っている場合は、それを見てみたいです。堅実で自明ではない参考文献を見つけるのはあまり運がありませんでした。Python での例は素敵ですが、喜んで何でも読みます。

編集1：

以下で非常に興味深いことが述べられていますが、一般的に、私が説明したアプローチに問題がある人は誰もいないようです。Vincent が説明している FrontController 設計は、すでにほとんど怠惰な形になっています。そのパターンを実装する上で問題が発生することは確かにないと思いますが、モデル間の通信に関する問題に実際に対処した人は誰もいないようです。すべての答えは、単一のモデル内のオブジェクト間の通信に対処しているようです。私は、アプリケーションの個別のコンポーネントに対して個別のモデルを維持することに関心があるので、50 の状態プロパティを 1 つのモデル クラスに詰め込みません。代わりにサブモデルとして維持する必要がありますか?

私は最近Railsプロジェクトを開始し、RESTfulコントローラーを使用することにしました。キーエンティティ（国など）のコントローラーを作成し、、、、、、、、を追加indexしましnewた。ルートファイルに自分を追加しましたが、生活は良かったです。editcreateshowupdatedeletemap.resources :country

開発が少し進んだ後、問題にぶつかり始めました。コントローラで追加のアクションが必要になることがありました。最初にsearch、私の凝った自動補完検索ボックスのオプションを返すアクションがありました。次に、アプリケーションのさまざまな場所で2つの異なる方法で国を表示する必要が生じました（表示されるデータも異なるため、2つのビューだけではありませんでした）-index_fullアクションを追加しました。次に、IDではなく名前で国をURLに表示したかったので、show_by_nameアクションを追加しました。

RailsのRESTfulコントローラーで標準のindex、、、、、、を超えるアクションが必要な場合はどうしますか？手動ルートをroutes.rbファイルに追加（および維持）する必要がありますか（これは面倒です）、別のコントローラーに移動しますか、RESTfulになりませんか、または基本的なものがありませんか？neweditcreateshowupdatedelete

私は質問していると思いますが、RESTfulであるという特権のために、もっと一生懸命働き、routes.rbファイルにアクションを追加する必要がありますか？map.resourcesRESTグッズを追加するために使用していなかった場合、標準:controller/:action, :controller/:action/:idルートはほとんどすべてを自動的に処理します。

コントローラーを書くためのお気に入りのパターンは何ですか?

私の見解にはフォームエリアがあります。ボタンをクリックするとA送信したい/Books/1ボタンをクリックするとB送信したい/Books/2

MVCでこれを達成するにはどうすればよいですか？

私は現在、データベースを使用してページ オブジェクトをセットアップするカスタム フレームワーク内で作業しています。ページ オブジェクトには、フロント コントローラーが MVC (明らかに) パターン内でルーティングなどを処理するために使用するモジュール、ビュー、コントローラーなどに関する情報が含まれています。

データベース内でページを処理する最初の理由は、管理インターフェース内からオンザフライで新しいランディング ページを作成できるようにする必要があり、他の動的オブジェクトをアタッチできる onLoad および onUnload イベントも作成する必要があったためです。

しかし、昨日この投稿を読んだ後、この処理をデータベースの外に移動し、データベースをコンポーネントにすることなくページをテストできるように、すべてのファイル構造とコードを他のフレームワークのように駆動するべきではないかと考えました。

私は現在、カスタム フレームワークを廃止し、標準フレームワークの 1 つを使用してそれを拡張するかどうかを検討しています (これが現在最も可能性が高いことです)。または、フレームワークに付属するルーティング/処理メカニズムをそのまま使用する必要があるか?

QDirModel現在のディレクトリが設定されています。次にQListView、そのディレクトリ内のファイルを表示するはずの があります。これはうまくいきます。

ここで、表示されるファイルを制限したいので、pngファイルのみを表示します (ファイル名は .png で終わります)。問題はQSortFilterProxyModel、フィルター正規表現を使用して設定すると、ファイルのすべての親も一致させようとすることです。ドキュメントによると：

階層モデルの場合、フィルターはすべての子に再帰的に適用されます。親アイテムがフィルターに一致しない場合、その子アイテムは表示されません。

QSortFilterProxyModelでは、ディレクトリ内のファイルのみをフィルタリングし、それが存在するディレクトリはフィルタリングしないようにするにはどうすればよいですか?

私は合計で約 2 年間 C# プログラマーであり、専門的には 1 年強です。.NET 2 の時代より前に始まったアプリケーションの開発者として会社で働いています。私の質問は次のとおりです。

SQL クエリからコントロールに直接データバインディングを使用して、クエリを実行し、項目を手動でコントロールに追加する利点は何ですか? このアプローチは一般的に、展開に関してよりクリーンでシンプルであると考えられていますか? 手動で追加すると、データの表示/値をよりきめ細かく制御できる場合がありますか?

クエリの結果に基づいて自分自身を設定するいくつかのコントロールを処理するいくつかのバグが割り当てられており、不要なロジックをクリーンアップして、それをライブラリにプッシュして代わりに処理したいので、私は尋ねています。

注: .NET 2.0 を使用しています

趣味のプロジェクトとして、私は現在、小さなブラウザー ベースのゲームを作成しようとしています。ゲームの「エンジン」をプレゼンテーションから分離して、MVC パターンを使用してコーディングするのが「正しいこと」だと思いました。これは単純な「RPG」ゲームで、プレイヤーのキャラクターが世界をさまよってモンスターと戦い、アイテムを収集します。

私の問題は、エンジンの構造に行き詰まったことです。現在の設計では、ほとんどのエンジンは「プレイヤーのキャラクター」オブジェクトによって支配されています。場所、モンスター、アイテムなどがありますが、移動、攻撃、アイテムの購入など、ほとんどのアクションを実行するのはキャラクターです。そのようなエンジンを設計するにはおそらく他の方法があることを知っていますが、どういうわけか私はそれを理解できないので、ここでいくつかのヒントやアドバイスを求めています.

ああ、サーバーのバックエンドは php+mysql になります。

Java に最適なフレームワークはどれですか? PHP 用の Symfony と Ruby 用の Ruby-On-Rails に似たものを探していますか? Javaにそのようなものが存在するかどうかさえわかりません。