10

Property Change オブザーバー パターンをサポートする Bean を作成する人がいることに気付きました。

import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
import java.io.Serializable;

public class SampleBean implements Serializable {
    public static final String PROP_SAMPLE_PROPERTY = "sampleProperty";
    private String sampleProperty;
    private PropertyChangeSupport propertySupport;

    public ChartBean() {
        propertySupport = new PropertyChangeSupport(this);
    }

    public String getSampleProperty() {
        return sampleProperty;
    }

    public void setSampleProperty(String value) {
        String oldValue = sampleProperty;
        sampleProperty = value;
        propertySupport.firePropertyChange(PROP_SAMPLE_PROPERTY, oldValue, sampleProperty);
    }


    public void addPropertyChangeListener(PropertyChangeListener listener) {
        propertySupport.addPropertyChangeListener(listener);
    }

    public void removePropertyChangeListener(PropertyChangeListener listener) {
        propertySupport.removePropertyChangeListener(listener);
    }
}

ただし、Web アプリケーションのステートレスな性質のため、オブザーバー パターンは Web ベースの MVC パターンでは一般的に使用されていないことを読んだことを覚えています。

Web アプリケーションのJava Beanで上記のパターンに従うのは良い方法ですか?

4

3 に答える 3

10

正直に言うと、実際にこの機能が必要になる場合にのみ気になります。ほとんどのWebアプリケーションはを必要としませんPropertyChangeSupport。私が見たWebアプリでそれが使用されているのを見たのを実際に思い出せません。私はそれがSwingアプリケーションで使用されているのを見ただけです。

Webアプリケーションの典型的なものbeanは、非常に短命なオブジェクトであり、単一の要求を処理する準備ができてから、ガベージコレクションのためにボイドにキャストされます。主な問題は、Webアプリケーションは私の存在の性質であり、マルチユーザーであり、リスナーやイベントなどを備えた長寿命のオブジェクトには向いていないということです。

于 2009-06-09T19:17:02.173 に答える
3

1) 必要になることがわかっている場合を除き、プロパティ変更サポートを追加しないでください。

2) Bean が getter/setter/equals/hashcode 以外の何もない単なる値オブジェクトである場合は、AOP フレームワーク (私は Spring が好きです) を使用して、プロパティ変更イベント/サポートを実装するために使用されるアドバイスでオブジェクトをラップすることを検討してください。このようにして、Bean は、特定のコンテキスト (通常は UI) でのみ必要とされ、さまざまなコンテキストで変更される可能性のあるロジックで汚染されないままになります。これは、特定のアプリのすべてのドメイン Bean にプロパティ変更のサポートを追加したときに学んだ教訓です。UI はそれを使用しましたが、サーバー チームを混乱させ (そこでは使用されませんでした)、使用されていない場所では単なるノイズでした。

また、個々のプロパティをリッスンする必要がない場合もあります。オブジェクト内の何かが変更されたかどうかを知るだけで十分です。

于 2009-07-29T17:10:22.660 に答える
3

PropertyChangeListenerとにかく、かなり貧弱なデザインです-すべての魔法の文字列の比較。ChangeListener（または類似の）単純なモデルを選択し、複合モデルと組み合わせる方がはるかに優れています。

インタラクティブで COMETy を実行していない限り、Web アプリケーションではあまり意味がありません。一般に、現在のすべての情報が一度にまとめられるプル モデルがあります。キャッシュがある場所は理にかなっているかもしれません。

Web アプリケーションと同じ方法でデスクトップ アプリケーションを作成することもできます。変更 (または一連の変更) を行い、GUI を同期します。これは非常にコンパクトであることがわかります。また、パフォーマンス コストは、主要な変更 (ウィンドウを開くなど) の重要な時間から移動され、サイクルが発生する重要でない時間に分散されます。

于 2009-06-09T19:45:26.513 に答える