Python PureMVC と Pubsub [終了]

Question

閉まっている. 。この質問はさらに詳しくする必要があります 集中した. 。現在回答を受け付けておりません。

---

この質問を改善したいですか? 1 つの問題のみに焦点を当てるように質問を更新します。 この投稿を編集する.

閉まっている 5年前.

Python アプリケーションを作成していますが、MVC を念頭に置いて実装したいと考えています。これを達成するために pubsub を使用するつもりでしたが、PureMVC に出会いました。

誰かこれら 2 つのこと、それらの違い、および一方を他方よりも使用することの影響について説明していただけませんか。

Answer 1

のことを指しているのだと思いますが、 pypubsub 私はそれについてよく知っています（私は著者です;）。でも、あまり詳しくないのですが、 Python 用 PureMVC.

PureMVC のドキュメントに基づくと、この 2 つは大きく異なります。ドキュメントを参照したりプレゼンテーションを聞いたりしたことに基づいて、選択する際に重要になると思われるいくつかの違いを以下に示します。

• 学習曲線：
  • pypubsub をアプリに組み込むのは簡単です。「メッセージトピック」を決定し、メソッドと関数を購読し、それらのトピックに送信メッセージを追加します。宛先へのメッセージの転送は自動的に行われます。「巡航速度」API は小さいです。あなたが持っている pub.subscribe そして pub.sendMessage 学ぶこと、そしてそれだけです。
  • PureMVC では、メディエーター、コマンド、プロキシなどについて学ぶ必要があります。これらはすべて、重要な機能を備えた強力な概念であり、事前に学習する必要があります。アプリの目的を「理解」し、いつ、どのように使用するかを「理解」するまでに、いくつかのアプリを作成する必要がある場合もあります。1 つのアプリの場合、オーバーヘッドにはそれだけの価値がある場合があります。このフレームワークを使用するアプリケーションを多数作成する場合には、価値があると考えられます。
• アプリケーション設計への影響:
  • PyPubsub:匿名オブザーバーのデザイン パターン。
  • PureMVC:MVC アーキテクチャ パターン。
  • pypubsub の「標準使用」で使用するクラスはありません。ほとんどの場合、メッセージをトピックに分類し、何をデータとして含めるかを決定する必要があります。これはかなり有機的に進化する可能性があります。新しいダイアログが必要で、フィールドを変更するとラベルが別の場所で変更されるように、その状態の一部を利用できるようにする必要があります。必要なのは、ダイアログにパブリッシュを含め、ラベルを更新するコードにサブスクライブを含めることだけです。むしろ、pypubsub を使用すると、デザインについて心配する必要がなくなります。むしろ、データをある場所から別の場所に取得する方法ではなく、機能に設計を集中させることができます。
  • PureMVC では使用するクラスが多数あり、そこから派生して登録し、基本クラスの機能を実装するようにコンポーネントを設計する必要があります。いくつかの新しいクラスを作成して、フレームワークによって呼び出されたときに適切な動作を行うように実装することなく、アプリケーション内のある場所からデータを簡単にパブリッシュし、別の場所でキャプチャできることは明らかではありません。もちろん、場合によっては、オーバーヘッド (設計にかかる時間) を考慮する価値があります。
• 再利用性:
  • コンポーネントがどのようなメッセージ トピックを発行し、何をリッスンするかを文書化している限り、別のアプリケーションに組み込んだり、動作の単体テストを行ったりすることができます。他のアプリケーションが pypubsub を使用しない場合、追加は簡単で、アーキテクチャには影響しません。すべてのアプリケーションで pubsub を使用する必要はなく、必要な場合にのみ使用できます。
  • PureMVC コンポーネントである OTOH は、すでに PureMVC に基づいているアプリケーションにのみ組み込むことができます。
• テスト容易性:
  • PureMVC は、レイヤー間で懸念事項を分離することでテストを容易にします。ビジュアル、ロジック、データ。
  • 一方、パブリッシュ/サブスクライブ (pypubsub) は、レイヤーに関係なく、パブリッシャーとコンシューマーを分離することでこれを容易にします。したがって、pypubsub を使用したテストは、コンポーネントで使用されるデータをテストで公開し、コンポーネントで公開されたデータをサブスクライブすることで構成されます。一方、PureMVC では、テストはビジュアル レイヤーとデータ レイヤーのふりをする必要があります。PureMVC でそれがどれほど簡単かはわかりません。
  • すべてのパブリッシュ/サブスクライブ システムは、アプリケーションが一定のサイズに達すると、適切なツールがなければデバッグが困難になる可能性があります。メッセージのパスを追跡するのは難しい場合があります。Pypubsub は、これを支援するクラス (開発中に使用される) と、パブリッシャーとリスナーに互換性があるかどうかを検証する機能を提供します。
  • PureMVC 図に基づくと、同様の問題が発生すると思われます。何か問題が発生した理由を理解するには、ファサードを経由して、プロキシ、コマンド、メディエーターをたどる必要があります。これに対処するために PureMVC がどのようなツールを提供しているのかはわかりません。
• 目的：
  • オブザーバー パターンは、一種の「データ バス」を介してある場所から次の場所にデータを取得する方法に関するものです。コンポーネントがバスにリンクできる限り、ソースまたはシンクの知識がなくても状態を交換できます。
  • PureMVC は次のようなアーキテクチャ パターンです。その役割は、ビュー、コントロール、データの観点からアプリケーションを簡単に説明できるようにすることです。モデルは、コントロールがモデルとどのように対話するかを気にしません。コントロールは表示方法を気にしません。ただし、ビューには、ユーザー アクションを処理し、表示するデータの目的のサブセットを取得するための特定のサービスを提供するコントロールが必要です (通常、利用可能なすべてのデータが表示されるわけではないため)。また、コントロールには特定のサービス (データを取得、変更するため) を提供するモデルが必要です。コントロールは、適切なタイミングでビュー コンポーネントをインスタンス化する必要があります。
• 相互排除:ドキュメントに基づいて、2 つのライブラリを同じアプリケーションで使用することを妨げる理由は思いつきません。これらは異なるレベルで機能し、異なる目的を持っており、共存することはできません。

すべてのデカップリング戦略には長所と短所があり、それぞれを比較検討する必要があります。学習曲線、投資収益率、再利用性、パフォーマンス、テスト容易性など。