Lời nói đầu

Khi nhiều người lần đầu tiên tiếp xúc với mùa xuân, họ vô cùng yêu thích @Autowired.

Chỉ với một chú thích, việc chèn phụ thuộc có thể được thực hiện dễ dàng, ngay cả số lượng mã hóa cũng được lưu.

Ai không thích nó?

Nhưng tăng dần, đặc biệt là trong các dự án phức tạp hơn, @Autowired bắt đầu cung cấp cho bạn một số thủ thuật.

Vì vậy, quan chức này đã đưa ra một số tài liệu và trao đổi cộng đồng: Không nên sử dụng @Autowired mà không suy nghĩ, Nhưng việc tiêm tạo ra sự kích thích hơn.

Tại sao? Có phải @Autowired không?

Nó đã hoạt động được, nhưng vấn đề là: nó không phải là bất khả chiến bại và có thể dễ dàng dẫn đến bẫy bẫy if use.

Vui lòng nói về lý do tại sao quan chức, khuyên bạn nên sử dụng @Autowired một cách cẩn thận và cung cấp cho bạn một số ví dụ về mã hóa. Tôi hy vọng nó sẽ hữu ích cho bạn.

1. Đường dẫn cập nhật phụ thuộc

Nhiều bạn thích viết trực tiếp tại nơi làm việc:

@Service lớp công khai MyService { @Autowired riêng tư MyRepository myRepository }

Nó có vẻ đơn giản, nhưng vấn đề ở đây là: các phần phụ thuộc của lớp bị ẩn quá sâu.

• Nhìn vào mã hóa này,Dịch vụ của tôi Và Kho lưu trữ của tôi Mối quan hệ thực chất là một “sự phụ thuộc vô hình”, phụ thuộc hoàn toàn vào @Autowired for in.
• Nếu đồng nghiệp chỉ lấy mã và mở ra thì anh ta sẽ không biết gì. kho lưu trữ của tôi Nó là gì và nó diễn ra như thế nào có thể dự đoán được thông qua IDE hoặc thời gian chạy.

Kết quả của sự phụ thuộc cao cấp là mã nhìn đơn giản nhưng khó bảo trì.

Việc thêm một phần phụ thuộc mới sau đó hoặc thay đổi thứ tự của các phần phụ thuộc có thể tạo ra cho mọi người rối loạn trong vài phút.

Làm thế nào để phá vỡ nó?

Thay vào đó hãy sử dụng nội dung xây dựng.

@Service public class MyService { Private Final MyRepository myRepository; // Nội dung hàm tạo, các phần phụ thuộc rõ ràng trong chớp mắt public MyService(MyRepository myRepository) { this.myRepository = myRepository } }

Lợi ích của công việc này là:

• Sự phụ thuộc rõ ràng:Ai phụ thuộc vào ai được viết trực tiếp trong hàm tạo một cách rõ ràng.
• Dễ dàng kiểm tra hơn:Nội dung xây dựng có thể truyền vào mô phỏng một cách thủ công để tạo điều kiện thuận lợi cho công việc viết bài kiểm tra đơn vị.

2. Sẽ dẫn đến sự gắn kết bền vững

Một ví dụ khác, nhiều người thích sử dụng trực tiếp @Autowired để đưa vào các cơ sở phát triển khai cụ thể, có giới hạn như:

@Service lớp công khai MyService { @Autowired riêng Cụ thểRepositoryRepository }

Nhìn bề ngoài thì không có gì sai, nhưng đây là mối ràng buộc chặt chẽ giữa MyService và SpecialRepository.

Điều gì sẽ xảy ra AnotherSpecificRepository, bạn sẽ phải thay đổi mã và chú thích, đồng thời các bài kiểm tra cũng sẽ giảm.

Làm thế nào để phá vỡ nó?

Sử dụng tính năng chèn giao diện và tạo chức năng để phân tách các phần phụ thuộc.

@Service lớp công khai MyService { kho lưu trữ cuối cùng riêng tư; MyService công khai (kho lưu trữ kho lưu trữ) { this.repository = kho lưu trữ;

Sau đó, công cụ định cấu hình phát triển có thể thông qua cấu hình tệp của Spring hoặc lớp @Configuration:

@Configuration lớp công khai RepositoryConfig { @Bean public Repository kho lưu trữ() { return Cụ thể mới() } }

Ưu điểm của công việc này là:

• Chuyển đổi hoạt động:Khi thay đổi lớp khai báo, không cần thay đổi cốt lõi logic mã hóa.
• Phù hợp với ý tưởng lập trình hướng dẫn:Giảm thiểu kết nối và cải thiện khả năng mở rộng.

3. Đường dẫn đến NullPointerException

Một số người bạn thích viết như thế này:

@Service lớp công khai MyService { @Autowired riêng MyRepository myRepository; public void doSomething() { myRepository.save(); // Bang!

Vấn đề là gì? NullPointerException.

Làm thế nào để phá vỡ nó?

Sử dụng hàm tạo để loại bỏ toàn bộ giá trị trống.

@Service lớp công khai MyService { Riêng tư Cuối cùng MyRepository myRepository; public MyService(MyRepository myRepository) { this.myRepository = myRepository; khởi tạo} public void doSomething() { myRepository.save();

Một ưu tiên khác của hàm tạo là việc tiêm thuộc tính bắt buộc. báo lỗi, phát hiện vấn đề sớm.

4. Lắp ráp tự động dễ gây nhầm lẫn

Cơ chế tự động kết nối của Spring đôi khi là "ma thuật đen", đặc biệt khi có nhiều loại đậu ứng cử viên trong dự án của bạn. Ví dụ:

@Service public class MyService { @Autowired Private Repository kho lưu trữ // Có hai lớp triển khai Kho lưu trữ trong vùng chứa, tôi nên làm gì? }

Nếu có hai lớp triển khai, chẳng hạn như Cụ thể và Kho lưu trữ khác, bộ chứa Spring sẽ báo lỗi trực tiếp. Có hai giải pháp:

• Chỉ định @Sơ đẳng.
• sử dụng @Qualifier Chỉ định thủ công.

Nhưng những phương pháp này làm cho mã trông phức tạp hơn và có thể dẫn đến cạm bẫy.

Làm thế nào để phá vỡ nó?

Xây dựng nội dung + cấu hình rõ ràng.

@Configuration lớp công khai RepositoryConfig { @Bean public Repository kho lưu trữ() { return Cụ thể mới() } }

Bạn cho Spring biết rõ nên sử dụng lớp triển khai nào. Đừng để vùng chứa đoán cho bạn, để tránh "thuốc không khớp" trong tương lai.

5. Viết bài kiểm tra đơn vị thật khó khăn

Cuối cùng, hãy nói về thử nghiệm.

@Autowired dựa vào Spring container để hoạt động, nhưng khi viết unit test thì không ai nghĩ đến Spring container (rắc rối và chậm). Kết quả là:

• Tiêm hiện trường:Không có cách nào để chuyển thủ công vào đối tượng giả.
• Lắp ráp tự động:Đôi khi không rõ Bean nào được sử dụng, khiến việc kiểm tra trở nên khó khăn.

Làm thế nào để phá vỡ nó?

Nội dung xây dựng vốn được thiết kế để thử nghiệm đơn vị.

lớp công khai MyServiceTest { @Test public void testDoSomething() { MyRepository mockRepository = mock(MyRepository.class); MyService myService = new MyService(mockRepository); // Kiểm tra logic} }

Bạn có thấy nó không?

Đưa trực tiếp đối tượng mô phỏng vào, bài kiểm tra rất đơn giản và tinh tế.

Tóm tắt

Tóm tắt ngắn gọn vấn đề:

1. Sự phụ thuộc ngầm làm cho mã khó đọc hơn.
2. Sự kết hợp mạnh mẽ đi ngược lại với lập trình hướng giao diện.
3. Tiêm hiện trường dễ bị NPE.
4. Có những cạm bẫy trong lắp ráp tự động.
5. Bài kiểm tra đơn vị rất khó viết.

Vậy chúng ta nên làm gì? Sử dụng nội dung xây dựng, rõ ràng, mạnh mẽ và thân thiện với thử nghiệm. Khuyến nghị chính thức không phải là không có lý.

Nhưng nói như vậy, không phải là @Autowired không dùng được mà chỉ là bạn ghi điểm cho cảnh đó thôi.

Trong quá trình phát triển, hãy phát triển thói quen sử dụng nội dung hàm tạo để làm cho mã của bạn mạnh mẽ hơn, đào ít lỗ hơn và thực hiện nhiều công việc hơn! .

Lời cuối cùng muốn nói (xin hãy chú ý đến tôi, đừng bán dâm tôi một cách vô ích)

Nếu bài viết này hữu ích hoặc truyền cảm hứng cho bạn, hãy giúp tôi theo dõi tài khoản công khai cùng tên của tôi: Su San nói về công nghệ. Sự ủng hộ của bạn là động lực lớn nhất để tôi tiếp tục viết. Vui lòng nhấp vào ba liên kết: thích, chuyển tiếp và xem. Theo dõi tài khoản công khai: [Su San nói về công nghệ] và trả lời trong tài khoản công khai: Nếu bạn vào một nhà máy lớn, bạn có thể nhận được hướng dẫn phỏng vấn miễn phí 100.000 từ mà tôi mới biên soạn. Nhiều bạn đã nhận được lời mời từ nhiều nhà máy lớn. các công ty bằng cách dựa vào hướng dẫn này.

Cuối cùng, bài viết này giải thích tại sao Spring chính thức không khuyến nghị sử dụng @Autowired? Bài viết này kết thúc như vậy nếu bạn muốn biết thêm về lý do tại sao Spring chính thức không khuyến nghị sử dụng @Autowired? Về nội dung, vui lòng tìm kiếm các bài viết của CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Tôi hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .