3

私はWeb開発者ではなく、Webアプリケーションフレームワークについてはよく知りません。

しかし、最近、私はWtに入りました。これはC++で記述されたWebフレームワークです（それが私がそれに取り掛かった理由です）が、私が最も感銘を受けたのは、それが基づいているアイデアです。

そのAPIは、私が今まで聞いたWebフレームワーク（CppCMS、Yii、Django、Pylons、Zope、Drupals、Javaサーブレット、Struts ...）とは異なります。新しいアプリケーションオブジェクトが任意のユーザーセッション用に作成され、セッションが期限切れになります（この時点でのみ、アプリケーションオブジェクトが破棄されます）。このアプリケーションオブジェクトはデスクトップウィンドウのように機能します。ウィジェットをその中に配置します（フォーム、リンク、ラベルなどのウィジェットなど）。ユーザーがリンクをクリックすると（HTTPサーバーが新しいGET / POSTリクエストを受信したとき）、ユーザーセッションに密着したオブジェクトで関数が呼び出されます（Signal / Slotの方法で）。これにより、削除/追加/変更が可能になります。ウィジェット、したがってユーザーに表示されるページを変更します。

私が言ったように、私はWebフレームワークにあまり精通しておらず、ほとんどデスクトップアプリケーションのみを開発しています。おそらくこの理由で、Wtの背後にあるこのパラダイムは素晴らしいと思います。

このフレームワークAPIの他のフレームワークとの長所と短所、および同じ概念に基づく他のフレームワーク（他の言語でも）があるかどうかを知りたいです。

4

3 に答える 3

3

Wtは、意図した範囲のアプリケーションに最適なフレームワークです。

Wtは次の用途に最適です：

  • セッションに緊密に結合されたWebアプリ、つまり
    • ログインしているユーザーのみがアクセスできるようになっています（ランディングページを除く）
    • ユーザーに依存するコンテンツをたくさん表示する（Wikiではない）
    • 状態に大きく依存している
  • 多くのコントロール/ボタンとユーザー入力が必要なWebアプリ。

たとえば、ブラウザMMORPGを作成する予定です。すべてのページはユーザーに関連付けられた状態になり、多くのボタンが表示されます。Wtはそのために最適です。私は以前RubyonRailsの開発者でしたが、この種のアプリをWtに切り替えるのは素晴らしい瞬間でした。純粋なRESTを適用しようとする従来のフレームワークを使用してフォームを設計するのは非常に面倒です。

Wtは、一部のプロセスの制御インターフェースにも最適です。たとえば、顧客がアドワーズ広告のキャンペーンを構成できるようにするインターフェイスなどです。

もちろん、Wtの使用は制御と分離に関して完全ではありませんが、「従来の」機能（ボタン、エディターなど）のみが必要な場合は、非常に高速な開発が可能になります。

したがって、経験則として、デスクトップアプリケーションをWebに配置しようとしている場合（これは、顧客のマシンに展開して更新する必要がないため、優れたアイデアです）、Wtが適しています。

また、既存のC ++コードベースとインターフェイスする場合、Wtには利点があります。

于 2011-11-16T17:40:33.160 に答える
0

これは一般的に悪い考えだと思います。

WebアプリケーションはGUIアプリケーションとは大きく異なり、多くの理由があります。

Webの99％は、反復ではなくコンテンツに関するものです。

絵を描いたり、スプレッドシートを操作したりするなどのリアルタイムのやり取りを行うのではなく、Webにアクセスしてコンテンツを取得または共有します。Webは、「イベント駆動型」の対話型アプリケーションではなく、コンテンツ駆動型です。

これは、ほとんどのWebを作成する方法に大きな影響を与えます。つまり、ユーザーと対話するのではなく、ユーザーに情報を提供します。

サーバーとクライアントのプログラミングは大きく異なります

電子メールやチャットクライアントなどのWebGUIアプリケーションがいくつかありますが、パフォーマンスを向上させるには、高品質のJavaスクリプトで記述されたクライアント側と、コンテンツ取得のためにAJAXで使用される高品質のサーバー側バックエンドを非常に適切に分離する必要があります。

Wtのように、または（他の既知のフレームワーク）この分離を隠すと、ソフトウェアが不安定になり、一般に、長期的には解決策よりも多くの問題が発生します。

リアルタイムの応答を必要とするものと必要としないものがあるため、サーバー側とクライアント側のジョブを非常に明確に分離する必要があるためです。

これらすべてを一度に解決しようとするときは、問題を待ちます。GUI用のクライアントサーバーソリューションがありますが（例としてX-Serverを参照）、Webとは異なり、これらはこのために設計されており、クライアントサーバーソリューションではなくIPCのように機能します。

ほとんどの場合、Webはステートレスです。

または、より正確に言うと、状態は通常、非常に少量のデータを保持します。

インスタントセッションオブジェクトの作成は、必要になるまでは良いアイデアです...長期的に保存状態をスケールアップすると、このモデルはあまり良くなりません。もちろん、これはWtによる「強制」モデルではありませんが、特定の概念に適合する一般的な概念であり、一部はそうではありません。

結論

Webアプリケーションのような優れたGUIを設計したい場合。JavaScriptの学習を開始し、GUI主導の設計にも適した優れたGUIJavaScriptフレームワークを使用します。次に、Json-RPC、XML-RPC、その他のAJAXツールなどのインタラクションRPCモデルを使用して、それらをサーバー側APIと組み合わせます。

これは、高度にインタラクティブなアプリケーションのために物事を正しく行う方法です。

アプリケーションがよりコンテンツ指向である場合、サーバー側のWebフレームワークのほとんどは優れた機能を果たします。その機能に適した優れたツールを使用して、サーバー側に集中してください。

オールインワンソリューション？それはうまくいきません...

開示：私はCppCMSの開発者であり、Wtは間違った方向に進んでいると思います。

于 2010-11-11T20:15:16.107 に答える
-1

ASP.NETも同様です。Web開発をデスクトップアプリケーション開発のように見せることも同じ目標です。

于 2010-11-11T18:31:09.590 に答える