Khi nào không sử dụng Spring để khởi tạo một hạt đậu?

Tôi đang cố gắng hiểu thế nào là cách sử dụng chính xác của Spring. Không cú pháp, nhưng về mục đích của nó. Nếu một người đang sử dụng Spring, thì mã Spring có nên thay thế tất cả mã khởi tạo bean không? Khi nào nên sử dụng hay khi nào không sử dụng Spring, để khởi tạo một bean?

Có thể mẫu mã sau đây sẽ giúp bạn hiểu được vấn đề nan giải của tôi:

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = new ClassA();
    ca.setName(name);
    caList.add(ca);
}

Nếu tôi cấu hình Spring, nó sẽ trở thành một cái gì đó như:

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = (ClassA)SomeContext.getBean(BeanLookupConstants.CLASS_A);
    ca.setName(name);
    caList.add(ca);
}

Cá nhân tôi nghĩ rằng sử dụng Spring ở đây là một chi phí không cần thiết, bởi vì

1. Mã đơn giản hơn để đọc / hiểu.
2. Đây thực sự không phải là một nơi tốt cho Dependency Injection vì tôi không hy vọng rằng sẽ có nhiều triển khai / đa dạng ClassA, mà tôi muốn tự do thay thế bằng cách sử dụng cấu hình Spring vào thời điểm sau.

Tôi có nghĩ đúng không? Nếu không, tôi sẽ sai ở đâu?

Bạn nói đúng, Spring không phù hợp với trường hợp sử dụng mà bạn đã liệt kê. Spring được sử dụng tốt hơn để quản lý các phụ thuộc bên ngoài (như cắm kết nối JDBC vào DAO) hoặc cấu hình (như chỉ định loại cơ sở dữ liệu nào sẽ sử dụng). Trong ví dụ của bạn, nếu loại đậu có thể thay đổi, thì bạn sẽ sử dụng giao diện để chỉ định hạt và khởi tạo hạt bằng cách sử dụng Factory. Bạn sẽ sử dụng Spring để chỉ định nhà máy nào sẽ sử dụng và đưa nó vào lớp cần thiết để khởi tạo các hạt. Sau đó, bạn có thể có một số nhà máy khác nhau tạo ra một số loại đậu khác nhau (tất cả đều hỗ trợ giao diện bean) và định cấu hình loại đậu phù hợp khi cài đặt (hoặc cập nhật).

Tôi sẽ sử dụng Spring (hoặc hệ thống DI khác) giữa các lớp, khởi tạo trực tiếp trong các lớp.
Vì vậy, một lớp tạo ra một bean rời khỏi phạm vi của lớp đó, đến một số hệ thống bên ngoài (có chức năng), có thể được xác định bởi hệ thống đó hoặc một số lớp truyền thông, sẽ được tạo thông qua DI. Một bean khác được tạo hoàn toàn để sử dụng nội bộ trong lớp ứng dụng được tạo trực tiếp, vì cả sự rõ ràng của mã và (trong các hệ thống lớn cũng quan trọng) vì lý do hiệu năng.

Nếu đó là một bean , bạn nên để Spring xây dựng nó (ngoại trừ bạn có thể cung cấp một bean nhà máy - Tôi đã sử dụng nơi mà tôi cần để trả về một lớp con cụ thể phụ thuộc vào một thuộc tính hệ thống - và bạn nên tham khảo tài liệu về @Configurationvà @Beanchú thích nếu bạn đang làm điều đó). Nếu nó không phải là một bean, mà chỉ là một đối tượng Java cũ, bạn không cần phải sử dụng Spring để tạo ra nó. POJO rất hữu ích, nhưng sẽ không bị tiêm phụ thuộc, trình bao bọc AOP, v.v. vì đó là những điều mà Spring bổ sung cho bạn.

Quyết định cơ bản là liệu nó có thực sự là một hạt đậu hay chỉ là một đối tượng bình thường xảy ra để tuân theo một số quy ước về đậu (ví dụ: đặt tên phương thức). Tôi không thể đoán đó thực sự là trường hợp từ ví dụ nhỏ mà bạn đã đưa ra.

Tôi có thể sai chuyên gia xin vui lòng sửa chữa.

Toàn bộ khái niệm về Bean trong bối cảnh mùa xuân là Spring Container đang chăm sóc đối tượng. Nó sinh ra nó là phạm vi vòng đời của cái chết, v.v ... Nó giống như nó là một người chăm sóc vật thể. Các ứng dụng cần nó tiêm nó.

Vì vậy, trong khi đưa ra quyết định trong quá trình thiết kế mô-đun của bạn, hãy luôn suy nghĩ liệu bạn có muốn Spring framework chăm sóc hay đó là một đối tượng đơn giản có vòng đời được đặt trong một phương thức.

Như các đối tượng dao đã đề xuất trước đây, các đối tượng hàng đợi jms v.v ... nặng và tốt hơn để lại cho chuyên gia đó là khung công tác Spring để chăm sóc nó.