4

編集、2020/09: 誰かが不思議に思っているなら、12 年後、はい、私たちは今では JSON と Kubernetes に移行しています。原文が続きます。

明らかに、すべての人のニーズを満たす単一のソリューションはありません。アーキテクチャは常にトレードオフです。もともと Web ゲームの RAD を対象としたフレームワークを作成したいと考えています。ターゲット言語は PHP ですが、アーキテクチャは広く適用できる必要があります。

このフレームワークの目標は次のとおりです。結果を達成できる方法の柔軟性。開発者にとって最大限の快適さ。LEGO® ブロックのようなモジュールの接続。多くのタイプの入力、多くのタイプの出力、処理のための 1 つのフォーマット。

優先事項ではない目標は、速度、企業での使用、および収益です。オープンソースプロジェクトのはずです。

この設計の要は、変換前のすべてのコンテンツが XML で処理されることです (アイデアは、私が使用した EAI システム eGate に基づいています)。データ抽象化レイヤー (できればスマートな ORM) は、現在は重要ではありません。出力は、XSLT またはその他のカスタム モジュールを使用して生成されます。事実上すべてのクライアント (古いブラウザー用の HTML、最新のブラウザー用の XHTML/HTML5、モバイル クライアント用のシンプルな HTML、AJAX/XMLRPC 用の XML など) に対応します。

XML を使用する主な理由は次のとおりです。

  • 有名な規格です
  • コンテンツをナビゲートおよび変更するための XPath、SimpleXML、および DOM などの既存のツール
  • コードを任意のタグ スープに変換するための強力で統一された方法を提供する XSLT
  • XML マークアップは非常に読みやすいので、JSON や YAML の利点がここで違いを生むとは思いません。
  • コンテンツは簡単に積み重ねることができ、XSLT で正しく変換されている限り、コンテンツの順序は重要ではありません。

ページ生成プロセスは、次のフェーズで構成されます。

  1. 前処理: モジュールの初期化、GPCS データの処理、デフォルトの [XML] テンプレートの適用
  2. 処理/生成: ビジネス ロジックの主要部分であり、肥大化した XML を最大限のデータで生成します (バラストを生成しないように最適化されていることを願っています)。
  3. 処理: いくつかの追加のビジネス ロジック。たとえば、マークアップの一部の削減、変換の準備、レポート、統計など。
  4. 後処理: 変換エンジン (ほとんどの場合 XSLT) を介して XML を解析し、出力します。

コンテンツは大量のメタデータ (タグ、権限、重要性、必要性、目的の出力タイプなど) を使用して生成され、後処理中に取り除かれます。

それで、私の質問は次のとおりです。速度を除いて、このソリューションの欠点は何ですか? フレームワークの開発/保守とそのアプリケーションの両方で、どこで問題が発生する可能性がありますか? このアーキテクチャの欠点は何ですか?

4

5 に答える 5

3

XSLT は管理がかさばる可能性があり、本質的に、開発者が作業しなければならない追加のプログラミング言語を追加します (少なくとも私があなたの説明を正しく理解している場合)。私の経験では、それを知っている人は比較的少なく、自分のやりたいようにできる人はさらに少ない.

于 2008-10-09T19:18:55.753 に答える
2

あなたに提案する「柔軟なフレームワーク」もわかりません。それはすべて、あなたが何に慣れているか、そしてあなたの個人的な好みに依存します.

私が知っていることの 1 つは、最初は XSLT がどれほど魅力的に見えるかということですが、XSLT から離れることです。XSLT を使用して Hello World のようなものや簡単な例を作成するのは非常に簡単です。ただし、XSLT を使用すると、より複雑なプロジェクトは完全に管理できなくなります (読めないことは言うまでもありません)。私の経験では、それがプロジェクトに大きな負担をかけるということです。

于 2008-10-09T21:08:46.517 に答える
1

非常に複雑なソリューションを見ていると思います。使用するスキーマを単純に設計して構築することは、大きな努力です。合計 5 ～ 6 人を超えるプロジェクトに参加している場合は、組織化されたスキーマ設計作業が必要になる可能性があります。この点はご承知のとおりかと思います。

フロントエンドでの PHP の選択について質問し、問題を提起する可能性があります。また、大きな意味で XML の決定を誤っていると思います。

これが私がすることです：

  1. Grails.org を使用してサービス層を構築する
  2. RESTFUL にできるすべてのリソースを残りの状態に保つ
  3. Grails で X-fire プラグインを使用して、構築が必要な SOAP サービスを構築します。
  4. Grails の GORM および RAD 機能を利用して、開発時間を短縮します。
  5. X または Y 言語またはプラットフォームでクライアントを構築して、これらのサービスを利用します。

私は、すべての XML 変換/処理を実行する純粋な Java の速度が絶対に必要です。大きなドキュメントがある場合、これらの処理にはかなりの時間がかかります。

あなたは自分の環境の力を誰よりもよく理解していますが、過度に設計するのではなく、最初に機能する最も単純なことを行うように注意してください.

于 2008-10-09T19:28:11.697 に答える
1

あなたが説明したことは、 toxを使用して実装できる可能性があります。ハイブリッドMVC-ARSアーキテクチャを使用します。私が見ている障害は、オラクルに依存しているため、toxが提示するコストポイントです。もちろん、オープンソースなのでPostgresql に変換することもできます。

于 2008-10-09T21:24:38.293 に答える
-2

私は過去にいくつかのWebゲームに取り組んできましたが、正直なところ、これほど複雑で扱いにくいものを必要としたことはありません。

于 2008-10-09T12:55:14.297 に答える