0

私はすでにCDI @Injectを使用して、一部のクラスでステートレス サービスを取得しています。

次の例のように、ドメイン オブジェクトを注入することも理にかなっているのだろうかと思います。

class UserSettings;

class User {
    //@Inject
    private UserSetttings settings = new UserSettings();
}

ユーザーは常に、後で変更できるいくつかのデフォルト設定を添付する必要があります。ここで CDI を使用しますか、それとも新しいオブジェクトを手動で作成することに固執しますか?

または、より一般的に言えば、一般的にどこで CDI を使用する意味があるのでしょうか? そして、どこではないのですか？

更新プロデューサー:

class Preferences {
    @Produces @DefaultSettings
    public UserSettings getDefaultSettings() {
        UserSettings settings = new UserSettings();
        //configure default
        return settings;
    }
}


class User {
    @Inject @DefaultSettings
    private UserSettings settings;
}
4

3 に答える 3

0

ユーザーは常に、後で変更できるいくつかのデフォルト設定を添付する必要があります。ここで CDI を使用しますか、それとも新しいオブジェクトを手動で作成することに固執しますか?

アプリケーションがCDI有効になっている場合CDIは、新しいオブジェクトを手動で作成するのではなく、 を使用する必要があります。

CDI を使用する一般的な意味はどこにありますか? そして、どこではないのですか？

CDIには多くの幅広い用途があり、開発者はさまざまな種類のコンポーネントを疎結合でタイプセーフな方法で統合するための大きな柔軟性を実現できます。したがって、CDI はすべてJava EE 6のEE 7アプリケーションで使用する必要があります。CDIがアプリケーションでサポートされていない場合は、使用しないでください。

于 2013-09-25T16:33:50.853 に答える
0

ドメイン オブジェクトを注入できます。おそらく、デフォルトのドメイン オブジェクトを注入するのではなく、その代わりにプロデューサを提供する必要があります。このプロデューサは基本的に、何らかの設定に基づいてドメイン オブジェクトを作成します。現在ログインしているユーザーなど、何かに基づいて必要なプロパティをオブジェクトにロードする「マネージャー」タイプのクラスを作成できます。現在、プリンシパルを取得し、それを使用してログインしているユーザーの情報を検索し、次のようなものを作成しますUserSettings。UserSettings拒否拡張機能を使用するか、インストールすることさえせずに、注入可能でないことを確認する必要があります。

別の方法 (私は特に好きではありませんが、機能する可能性があります) は、ドメイン オブジェクトが永続化ドメインへの参照を挿入してデータを検索することです。概念的には、少しきれいに見えます。セットアップ コードは@PostConstructメソッドに記述します。

于 2013-09-25T21:44:27.953 に答える
0

もう 1 つの側面を追加したいと思います。優れたコードはテストできるということです。また、依存性注入を使用して「制御の反転」をサポートすることは、常に良い考えです。設定が内部的に作成されている場合、コードをどのようにテストするかを考えてください。

private final UserSettings s = new UserSettings();...

注入可能にしてから、テスト スコープで注入フレームワークを使用する方がはるかに簡単です (ヒント: 針 ( https://github.com/akquinet/needle ) を使用します)。

于 2013-09-26T08:55:56.887 に答える