問題タブ [model-view-controller]

MVC アプリケーションを修正して安定させる必要がある場合、モデル、コントローラー、またはビューのどこから始めますか? 問題はアプリケーション全体に均等に広がっており、機能を追加するのが困難な不適切なプログラミング プラクティスがあります。それが違いを生む場合、アプリケーションはPHPで書かれています。

私は主に Web 開発者ですが、C++ と C# についてはよく理解しています。しかし、最近、GUI アプリケーションを作成していて、コントローラーとビュー ロジックの関係を処理する方法に迷い始めました。PHP では非常に簡単で、目を閉じたまま独自の MVC パターンを作成できました。主な理由は、PHP がステートレスであり、リクエストごとにフォーム全体を再生成するためです。しかし、アプリケーション プログラミング言語では、すぐに道に迷います。

私の質問は、コントローラーをビューから分離するにはどうすればよいですか? ビューはコントローラーからのイベントにアタッチする必要がありますか? または、ビューはコントローラーが対話するインターフェイスを実装する必要がありますか?

一般に、MVC フレームワークには次のような構造があります。

ただし、Web アプリケーション スイートでは、システムをアプリケーション スイートではなく 1 つのアプリケーションとして扱わない限り、すべてのモデル、ビュー、およびコントローラーをひとまとめにすることはおそらく最善ではないだろうと判断しました。ただし、ユーザーとユーザーの役割の概念のように、すべての「アプリケーション」を結び付けるものがあります。

だから私は3つの可能な解決策があります：

(1) 本当にやりたくないことをして、どのアプリに属しているかに関係なく、すべてのモデル、ビュー、およびコントローラーを一緒に保ちます。これは、スイートを単一のアプリケーションとして扱っています。これは、ユーザーを含むいくつかの共通スレッドによって結び付けられているためです。

(2) アプリケーションごとにコードをグループ化します。

(3) コードをタイプごとにグループ化し、ユーティリティ コードをすべてのアプリケーションで共有できるようにします。

見逃したオプションはありますか？将来の開発者にとって最も論理的なスキームは何ですか? 私は個人的には 2 と 3 を好みますが、おそらくほとんどの人は 1 を期待するでしょう。

どちらを選択するか（MVCまたはMVP）を尋ねているのではなく、2つのうちの1つをWebアプリケーションに使用する必要があるかどうかを尋ねていることに注意してください。

古いアプリケーションを現在の設計からMVCまたはMVPパターンに変換するのは大変な作業かもしれないことを私は理解しています。しかし、新しいアプリはどうですか？これらは最も人気のあるアーキテクチャパターンのようですが、そのうちの1つを選択する必要がありますか？そうでない場合、他にどのようなパターンがありますか？

MVCやMVPに精通していない場合は、「MVPとMVCとは何ですか、違いは何ですか？」を確認することをお勧めします。。それぞれを分解するさまざまなウェブサイトへのリンクを含む、多くの良い答えがあります。

Global.asax.csに次のものがあります

私の SearchController は次のようになります

Index.aspx は、現時点では単に ViewData["partnerID"] を示しています。

Windows XP の IIS に Test という名前の仮想ディレクトリをセットアップしました。

ブラウザでhttp://localhost/Test/を指定すると、期待どおりに 1000 が表示されます。ただし、http://localhost/Test/1000を試すと、ページが見つからないというエラーが発生します。何か案は？

仮想ディレクトリで MVC を実行するための特別な考慮事項はありますか?

ASP.NET MVC のユーザー コントロールにグラフを追加したいと考えています。この問題に取り組む方法についてのアイデアやガイドを期待しています。私は周りを検索しましたが、この問題を解決するための役立つ答えは見つかりませんでした. Crystal レポートを作成することを考えていましたが、以前の経験から ASP.NET ではうまくいきません。この問題に取り組むためのいくつかの方法を知りたいだけです。繰り返しますが、私がやろうとしているのは、ユーザー コントロールに渡された ViewDataDictionary から MVC ユーザー コントロールにグラフを追加することです。

何かがビューまたはコントローラーに入るかどうかをどのように判断しますか?

以下に具体的な例をいくつか示します。

• Zend_Captcha: コントローラがキャプチャを生成してビューに渡しますか、それともビューがキャプチャを生成しますか?
• Zend_Alc: ビューのセグメントをユーザーに表示するかどうかをビューが決定しますか?それとも、使用可能なアクションに応じて複数のビューがあり、コントローラーが表示に適したビューを選択しますか?
• Zend_Session: ビューは、セッション データに基づいてビューを表示しているユーザーを追跡しますか?それとも、コントローラーによって解析され、何らかのパラメーターとしてビューに提示されますか?

どのコンポーネント (モデル、ビュー、またはコントローラー) が何をすべきかについてのルールまたはガイドラインは、私が見ることができる場所に書かれていますか? Zend Framework サイトのドキュメントにはそれがありませんでした。

私は、ログインフォームのようなものが必要なときにビューでデザインしてページを作成したPHPのバックグラウンドから来て、MVCにかなり慣れていません。login というファイルがあります。これは、別のタイプのユーザーにログインするために新しいログインフォームが必要な場合にのみひどいものでした. 管理人と言います。次に、login-admin.php などと呼ばれる新しいページを作成する必要があります。

最近、私は MVC、特にフレームワークについて調べ始めましたが、私が抱えている最大の問題は、コントローラーをどのように正確に作成するかを決定することです。ビュー ファイル ルートごとに 1 つのコントローラーを使用するか、ドメイン オブジェクトに基づいてコントローラーを取得するように言われました。

ユーザーコントローラーと、ユーザー/追加、ユーザー/編集、ユーザー/削除、ユーザー/プロファイルなど、そのオブジェクトを操作するための多くのメソッドを使用できることを理解しています。しかし、この例では、「ドメイン オブジェクト」内に収まるとは限らないビューが必要になると、それらをどこに貼り付けるかを決定するのが難しいようです。

では、コントローラーを決定する際のベストプラクティスは何ですか???

Python アプリの MVC パターンのモデル部分でクラスを構造化する際に問題があります。どのように物事を変えても、循環インポートに遭遇し続けます。ここに私が持っているものがあります:

モデル/__init__p.y

• すべてのモデルクラス名を保持する必要があるため、コントローラーまたはユニットテストケースなどから「モデルインポートユーザーから」実行できます

モデル/データベース.py

• データベースクラスを保持
• ORMを行うには、すべてのモデルクラスをインポートする必要があります
• 初期化は最初のモジュールのインポート時に実行する必要があります。つまり、余分な init 呼び出しやインスタンス化はありません (データベース クラスのすべてのメソッドは @classmethods です)。

モデル/User.py

• User モデル クラスを含む
• クエリを実行するには、データベース クラスにアクセスする必要があります
• 機能を共有するために、すべてのモデル クラスに共通の基本クラスから継承する必要があります (データベース永続化メソッド、パラメーター検証コードなど)。

私はまだ MVC を採用している実際の Python アプリを見たことがないので、私のアプローチはおそらく非 Pythonic です (そしておそらく言語にとらわれない混乱です...) - これを解決する方法について何か提案はありますか?

ありがとう、サイモン

ビュー内の複雑なコンポーネント間の相互作用を調整するためのベスト プラクティスは何ですか?

コンボ ボックスやグリッド コントロールのような単純なウィジェットについて話しているのではなく、複数のウィジェットで構成されていて、それ自体で単体テストを行うに値するコンポーネントについて話しているのです。

あなたは：

1. 各コンポーネントの抽象インターフェースを定義し、コントローラーに任せる依存性注入を介してそれらを接続し、メソッド呼び出しを介して互いに直接通信できるようにしますか? したがって、コンポーネントは他のコンポーネントのインターフェースを認識します。
2. 各コンポーネントが起動できるイベントを定義し、コントローラーに任せるイベントリスナーを介して相互に直接接続しますか? したがって、コンポーネントには、他のコンポーネントのイベント シンクにアタッチされたイベント ハンドラがあります。
3. 各コンポーネントの抽象インターフェイスを定義し、それらが起動できるイベントを定義し、コントローラーに任せるすべてのイベントをリッスンし、インターフェイスでメソッド呼び出しを実行しますか? したがって、コンポーネントは他のコンポーネントに対して完全に不可知です。
4. オブザーバー パターンの古典的なアプリケーションですか?
5. 他に何か？

更新: #1 から 3 までの「let the Controller ...」を削除しました。これらの場合、ルーティング/オーケストレーションを行う必要があるのは必ずしも Controller であるとは限らないためです。ビュー自体である可能性があります。

最近のプロジェクトで方法 3 を採用しましたが、コンポーネントのデカップリングと個々のテスト容易性に満足しています。しかし、コンポーネントの配線を合理化できた気がします。私の場合、メインの View オブジェクトは、各コンポーネントに複数のイベント リスナーを追加し、適切なコンポーネントのメソッドを呼び出す必要があります。これは、時々ローカル処理 (モデルとの対話など) を行った後に行います。イベント ハンドラーを追加するためのコードは少し乱雑に見えます。特に、それを行うクリーンな方法を探しています。