8

答える前に、この質問は複雑です。

  1. 私たちはasp.net / asp.net mvc / jQueryで開発していますが、どのフレームワークを使用するどのプラットフォームでもソリューションを受け入れています
  2. 並べ替え/列の非表示/列の再配置/検証(意味のある場合)などのロジックはクライアント側にある必要があると思います
  3. データベースの検索/更新/ワークフローの実行などのロジックはサーバー側にある必要があると思います（セキュリティ/デバッグ上の理由から）

私たちがやろうとしているのは、さまざまなコンテキストで同じ機能を処理するために大量の JavaScript を記述して、UI を混乱させないことです。JavaScript ファイル + オブジェクト指向 JavaScript を使用できることを理解しています。それをすべて簡単にするパターンを探しています。

提案された 1 つの解決策は、クライアント側とサーバー側の両方に MVC モデルを用意することでした。これにより、JavaScript 機能をクライアント側コントローラーにカプセル化し、サイトのさまざまな部分で使用できます。ただし、これは 2 つの MVC 実装があることを意味します。

これはやり過ぎですか？このソリューションをどのように拡張しますか? 他にどのような解決策がありますか?

4

6 に答える 6

3

単純にする。MVCASP.Netフレームワークで完全に機能するようにアプリケーションを構築します。テストのこの段階ではJavaScriptは必要ありません。

次に、site.master（Googleリンク）でjQueryをリンクし、Web 2.0エクスペリエンスを必要とするビューの下部で、機能を目立たないように追加する適切なJSファイルにリンクして、優れた機能を追加します。JSをオフにすると、アプリは前の手順に戻ります。

たとえば、サーバー側に加えてクライアント側の検証を追加するとします。JSファイルは、onsubmitフォームにイベントハンドラーを添付します。ハンドラーは、サーバーによって生成されたオブジェクト（サーバーの検証に使用されたものと同じオブジェクト）を使用します。これは、JSおよびASP.NETと互換性があるため、JSONオブジェクトとして最適です。オブジェクトのメンバーは、サーバー側のエラーを選択したのと同じ場所でDOMに書き込むためのチェックメッセージとエラーメッセージのルールになります。ハンドラーは、すべてが有効になるまでfalseを返し、正しい場合はtrueを返します。

写真のライトボックスビューなど、すばらしい機能が必要です。ビューのプラグインを追加し、マークアップを変更します<ul id="lightup">...、コードを追加します。

$（function（）{
   $（＃lightup）.showit（400）; //またはそのようなもの
}）;

とあなたの良い行きます。

共有機能をサーバーコードからWebサービスまたはページに分離して、クライアントがXHRとサーバーを介して同じ機能/データを共有できるようにしてください。

于 2009-03-11T17:26:53.487 に答える
3

私はこれをグーグルで検索したので、それを一粒の塩で取ってください。 JavascriptMVCは、MVC フレームワークであると主張しています。繰り返しますが、私はそれについての経験はありませんが、一見の価値があるかもしれません.

于 2008-10-18T11:51:23.427 に答える
2

二人で; 常にサーバー側の検証とクライアント側の検証が必要です

3つに; クライアント側でDBを操作する方法を見つけることができれば、それは印象的です;）

ASP.netがどのように機能するかはわかりませんが、PHPの経験からのみ話しています。

サーバーとクライアントのコードでペアになっているコントロールを作成します。各コントロールには、フォーム、クライアント側ロジック、およびサーバー側ロジックが必要です。フォームはテンプレートエンジンによって書き出され、クライアント側のロジックはフォームにアタッチされてJSで書かれ、サーバー側のロジックはモデルを操作するコントローラー/アクションのペアです。明らかに、クライアント側のロジックを特定のアクション/コントローラーに結合したくないので、代わりにコントロールとの通信に使用できるインターフェイスを定義してください...

次に、フォームごとに、コントロールをインスタンス化するクラスをJavaScriptで記述します。例えば; あなたはコントロールを持っているかもしれません：

{include file = "list_view.php" id = "ListView1" data = $Data.List}

フォームを印刷します。次に、ページコントローラクラスで：

this.ListView1 = new ListViewController({id : "ListView1", serverCtrl : "Users"});

これで、「this.ListView1」を使用してリストビューを操作できます。リストビューコントローラーは、使用時に次のページボタンが押された場合に新しいページのAJAXクエリを作成するなどの処理を行い、列と並べ替えも処理します（これもサーバーに委任されます）。

于 2008-10-17T19:22:37.540 に答える
1

MVCを使用している場合、ビューはテンプレートエンジンを利用していると思います。各ページはテンプレートに関連付けられており、各テンプレートには通常、1つ以上のスクリプトへの参照が含まれています。問題は、スクリプトがテンプレートでどのように参照されているかということです。それらは静的ですか、それとも動的ですか？コントローラ内では、テンプレートに関係なく、ページに使用されるビューにスクリプトを含めるオプションが必要です。MVCクライアント側をシミュレートすることは、まさにあなたが言ったことを意味するため、この「必要に応じて含める」アプローチを提案することがよくあります。現在、2つのMVCフレームワークを維持する必要があります。それだけでなく、ほとんどのクライアント側モデルでは、サーバー側モデルに直接アクセスできるため、サーバー側MVCの目的が損なわれます。これで、コントローラーを完全にバイパスしています。

JavaScriptに関しては、JavaScriptを非常にシンプルに保つことが最善の方法です。jQueryを使用すると、これを実現する可能性がさらに高くなります。すべてのページがコアを取得し、同じフォルダーに他のいくつかのJavaScriptファイルがあり、それぞれが非常に特定の機能にマップするjQueryオブジェクトのプラグインまたは拡張機能です。開発者が機能がすでに存在するかどうかを知りたい場合は、JavaScriptファイルが配置されているファイルシステムを確認するだけです。プラグインが存在する場合は、ページで使用するためにコントローラーにプラグインを含めます。このようにして、クライアント側のアプリと既存のコントローラーの間にあるサーバー側にヘルパーを構築できます。ヘルパーはその機能とプラグインに固有であり、クライアント側からモデルへの包括的なアクセスを開くことはありません。

于 2008-10-19T22:57:50.163 に答える
1

json/xml をビューに返さず、クライアントで jquery dom 生成を使用してビルドします。まともなマシンではパフォーマンスに関しては問題ありませんが、私はこの間違いを犯し、iPhone でサイトを表示しようとすると、読み込みに 60 秒かかります...そしてサイトにいるのは私だけです! :-)

したがって、この時点では、ajaxy の更新に jquery dom Injection を使用し、ページ全体をレンダリングしません。

于 2009-08-11T15:42:12.013 に答える
-1

... 場合によります...

実際、最良の方法は、スタイル/動作/構造 + データに css / javascript / html を使用して UI を開発することです。最近では、人々は ajax 相互作用を望んでいます (彼らはどこでもクールなものを見ているので、そうする必要がないことを期待しています)。毎回ページ全体をリロードします) ので、これを考慮に入れる必要があると思います。ところで、MVC はコンテンツが提供されると終了します。HTML コンテンツである必要はありません。ビューで xml または json を提供できます。

ASP.NET MVC は Content("TEXT") を返すことを許可するため、MVC と JavaScript でのユーザー インタラクション/動作を使用してバックエンドを整理できます。たとえば、ajax 呼び出しがサーバーに送信されたときに、アプリケーションのコントローラー部分を呼び出している場合、したがって、JSON としてレンダリングし、UI の JS 部分 (動作部分) に戻る ajax モデルに切り替える Ajax アクションを呼び出すことができます。

Behavioral 部分は View 部分で定義されているため (初期 View は CSS / HTML JS で構成されています)、プレゼンテーション部分である限り、MVC パターンを壊していないと思います。

PS。明らかにDBアクションがモデルにとどまるということを忘れていました（モデルは、データアクセス層+ビジネスオブジェクト層がとどまる場所と考えることができます）

于 2008-10-17T19:24:54.977 に答える