3

次の例で依存性注入を使用しますか？

@Scope("prototype")
@Component
public class Order{
    @Autowired
    public Order(User user,List<OrderItem> items,.......){

今どこか別の場所：

@Component
public class PersistOrder{
    @Autowired
    Provider<Order> orderProvider;

    public void prepareOrder() {
        Order order = orderProvider.get();

JSR-330が述べているように、Providerのget（）メソッドはOrderの新しいインスタンスを返しますが、どのオブジェクトが新しいorderのコンストラクターに渡されますか？ご覧のとおり、注文には独自の依存関係があり、実際の注文オブジェクトをメソッドに取得する前に注入する必要があります。

DIを使用しない場合は、必要なすべての引数を作成し、それらを新しい順序のコンストラクターに渡すだけです。では、ここでDIを使用する必要がありますか？

編集：

これは、コードがDIなしで表示されるものです。

@Component
public class PersistOrder{

    public void prepareOrder() {
        User user=userDao.get(userId);
        List<OrderItem> orderItems=orderItemDao.getAll(orderItemIds);
        Order order = new SmartPhoneOrder(user,orderItems);

ご覧のとおり、私はユーザーと注文アイテムのIDを持っており、DAOからそれらのインスタンスを取得できます。次に、これらのインスタンスをOrderのサブクラスのコンストラクターに渡して、インスタンスを取得します。プロセスは私には非常に明確に思えます。つまり、コードがPersistOrderクラスとOrderクラスの間のデカップリングを楽​​しむことができるように、DIでこの作業をどのように行うことができますか？または、この例でDIを使用すると、ロジックがより複雑になりますか？

4

1 に答える 1

3

依存性注入がなければ、ドメイン オブジェクトは貧血と見なされる可能性があり、これは間違いなくアンチパターンです。関連する動作がなくてもデータ構造を持つことで、オブジェクト指向の利点の多くを失うことになります。たとえば、 Order.isValid() を評価するには、検証を実行するために何らかの依存関係を注入する必要がある場合があります。

以下を使用して、Spring コンテナーのコンテキスト外のクラスで依存性注入を取得できます。

@Configurable

次に、Bean のレシピをプロトタイプとして宣言すると、Spring は AOP を使用してコンストラクターをスウィズルし、必要な依存関係を検索します。. 依存関係を検索しても、最終的な効果は依存関係の挿入です。これは、Order.isValid() を評価する別のものを挿入するために 1 行を変更するだけでよいためです。

このようにして、新しい注文を行うか、永続化ファクトリから取得すると、依存関係が既に「注入」されています。

これを行うには、デフォルトである Proxy/CGLib ウィービングだけでなく、aspectJ ウィービングが必要です。Java エージェントを使用した実行時ウィービングまたはビルド時ウィービングのいずれかを使用できます。. . 統合テストには前者を、展開には後者をお勧めします。. .

サービスとドメイン オブジェクト:

豊富なドメイン オブジェクトを選択できるようになったので、どこに何かを配置するかが問題になります。サービス対エンティティ？私の見解では、サービスは再利用可能なドメイン オブジェクトに基づいて、ユースケース固有のプロセスを調整する必要があります。このサービスは、外部サブスクライバがシステムにアクセスするための非 OO ゲートウェイです。

. . ドメイン クラスの AspectJ ベースの依存性注入に関する詳細とチュートリアルについては、Google Spring @Configurable を参照してください。

于 2013-01-12T03:21:58.430 に答える