Xử lý phụ thuộc vòng tròn trong CDI

Question

Tôi có tình huống như thế này. Tôi không thể thấy bất kỳ lỗi nào nhưng tôi không nhận được kết quả của mình.

@ApplicationScoped 
public class A { 

    private B b; 


    @Inject 
    public A(B b) { 
     this.b = b; 
    } 
} 

@Singleton 
public class B { 

    private A a; 


    @Inject 
    public B(A a) { 
     this.a = a; 
    } 
} 

Loại tiêm phụ thuộc này có sai không?

Bất kỳ ai cũng có thể giúp tôi với điều này.

Answer 1

Tôi muốn tránh sự phụ thuộc vòng tròn này, có một vài lý do để làm điều đó.

Nhận xét về this article

Một constructor lộn xộn là một dấu hiệu. Nó cảnh báo tôi rằng lớp học của tôi đang trở thành một khối nguyên khối, đó là một jack của tất cả các ngành nghề và một bậc thầy của không. Nói cách khác, một nhà xây dựng lộn xộn thực sự là một điều tốt. Nếu tôi cảm thấy rằng các nhà xây dựng của một lớp học là quá lộn xộn, tôi biết rằng đó là thời gian để làm một cái gì đó về nó.

Và this one

Bạn sẽ tìm thấy trường hợp một lớp A cần một thể hiện của B và B cần một thể hiện của A. Đây là một trường hợp điển hình của một phụ thuộc vòng tròn và rõ ràng là xấu. Theo kinh nghiệm của tôi, giải pháp là làm cho B trở thành một phần của A khi hai người phụ thuộc quá mạnh đến nỗi họ thực sự nên là một lớp. thường xuyên hơn dù có thêm ít nhất một C ẩn lớp trong đó để B không cần A nhưng chỉ C.

Như Oliver Gerke commented:

Đặc biệt constructor injection thực sự ngăn cản bạn giới thiệu các phụ thuộc cyclic. Nếu bạn giới thiệu chúng, bạn về cơ bản làm cho hai bên một bởi vì bạn không thể thực sự thay đổi một mà không có nguy cơ để phá vỡ khác, mà trong mọi trường hợp là một mùi thiết kế.

Đây là một ví dụ nhỏ về những gì tôi có thể làm.

public class A { 

    private B b; 

    @Autowired 
    public A(B b) { 
     this.b = b; 
    } 

    public void doSomeWork() { 
     // WORK 
    } 

    public void doSomeWorkWithB() { 
     b.doSomeWork(); 
    } 
} 

public class B { 

    private A a; 

    @Autowired 
    public B(A a) { 
     this.a = a; 
    } 

    public void doSomeWork() { 
     // WORK 
    } 

    public void doSomeWorkWithA() { 
     a.doSomeWork(); 
    } 

} 

Sau khi tái cấu trúc, nó có thể trông như thế này.

public class A { 

    private C c; 

    @Autowired 
    public A(C c) { 
     this.c = c; 
    } 

    public void doSomeWork() { 
     // WORK 
    } 

    public void doSomeWorkWithC() { 
     c.doSomeWorkThatWasOnA(); 
    } 

} 

public class B { 

    private C c; 

    @Autowired 
    public B(C c) { 
     this.c = c; 
    } 

    public void doSomeWork() { 
     // WORK 
    } 

    public void doSomeWorkWithC() { 
     c.doSomeWorkThatWasOnB(); 
    } 

} 

public class C { 

    public void doSomeWorkThatWasOnB() { 
     // WORK 

    } 

    public void doSomeWorkThatWasOnA() { 
     // WORK 
    } 

} 

Answer 2

Bạn cũng có thể sử dụng Setter based Dependency Injection để giải quyết vấn đề này.

Answer 3

Trích dẫn từ Phần 5 của CDI Specification 1.2:

Các container được yêu cầu hỗ trợ circularities trong sự phụ thuộc đồ thị đậu nơi ít nhất một đậu tham gia mỗi chuỗi tròn phụ thuộc có bình thường phạm vi, như được định nghĩa trong Phạm vi thông thường và phạm vi giả. Thùng chứa không được yêu cầu để hỗ trợ chuỗi vòng phụ thuộc mà mỗi hạt tham gia trong chuỗi có phạm vi giả.

ApplicationScoped là phạm vi bình thường, vì vậy chu trình này sẽ hoạt động.

Trong mẫu của bạn, lớp A không thể được ủy quyền vì nó thiếu một hàm tạo không đối số. Thêm hàm tạo này (có thể đã được bảo vệ hoặc hiển thị gói), mẫu của bạn triển khai không có vấn đề gì.

Answer 4

Chắc chắn có một giải pháp cho việc này. Hãy để tôi quote bản thân mình:

Giải pháp đúng là tiêm javax.enterprise.inject.Instance, trong đó T là loại của lớp được tiêm. Vì kiểu này là trực tiếp Foo, việc gọi phương thức get() trên một đối tượng được đánh máy là Instance được bảo đảm để tiêm đối tượng thích hợp mọi lúc. Cách tiếp cận này hoạt động rất tốt, bởi vì cá thể được lấy tự động từ thùng chứa bởi bản thân việc triển khai thực hiện và chỉ khi cần thiết. Do đó, trách nhiệm truy xuất phụ thuộc được để lại cho mã của bạn - mã của bạn có trách nhiệm không tạo ra vòng lặp vô tận.

@Named 
public class Foo implements Fooable{ 

@Inject 
private Instance<Foo> foo; 

public void executeFirst(){ 
foo.get().executeSecond(); 
} 

@Transactional 
public void executeSecond(){ 
//do something 
} 

}