IOC và dịch vụ phi trạng thái. Sống ngắn hay đơn lẻ?


8

Với một khung được thu gom rác, khi sử dụng một thùng chứa IOC để tiêm các dịch vụ hoàn toàn không trạng thái, nói chung là tốt hơn để sử dụng tuổi thọ cá thể của bộ chứa hoặc để tạo lại đối tượng mỗi khi nó được sử dụng và vứt bỏ nó, và tất cả các phụ thuộc của nó, đi ngay khi bạn hoàn thành với họ?

Câu trả lời:


5

Bạn đề cập rằng dịch vụ của bạn có phụ thuộc.

Nếu bất kỳ sự phụ thuộc nào trong biểu đồ phụ thuộc của bạn không hoàn toàn không trạng thái, hoặc nếu một trong những phụ thuộc của bạn trong biểu đồ phụ thuộc của bạn sẽ được sửa đổi để không còn hoàn toàn không trạng thái nữa, thì toàn bộ hệ thống sẽ thất bại. Và các lỗi bạn nhận được có thể sẽ rất khó hiểu, do đó gây khó khăn cho việc phát hiện ra vấn đề.

Giả sử bạn là một nhóm các nhà phát triển làm việc trong dự án. Rất khó có khả năng mỗi người trong số họ đều biết rằng cấu hình IOC yêu cầu tất cả các thành phần này phải hoàn toàn không trạng thái. Họ có thể biết điều đó ngay bây giờ, nhưng nhận thức đó sẽ mờ dần theo thời gian. Và nếu bạn thuê một anh chàng mới, anh ấy / cô ấy cũng sẽ không nhận ra.

Vì vậy, tôi chắc chắn sẽ thiết lập bộ chứa IOC để trả về một thể hiện mới mỗi lần. Nó chỉ đơn giản là sự lựa chọn an toàn hơn, imho.

Tôi chắc chắn sẽ không lo lắng về tài nguyên. Chi phí xây dựng và thu gom rác của các đối tượng có lẽ không đáng kể so với ví dụ chỉ là một tra cứu cơ sở dữ liệu.


Vì vậy, bạn đang nói để tạo các phiên bản mới mỗi lần vì bạn có thể không biết cách làm cho dịch vụ không trạng thái?
Matthew Flynn

1
Không. Điều tôi đang cố gắng nói là có thể khó dự đoán cơ sở mã của bạn sẽ được sửa đổi theo thời gian như thế nào. Nhưng câu hỏi cực kỳ chung chung, vì vậy tôi đang đưa ra một câu trả lời cực kỳ chung chung;)
Pete

Vâng, câu hỏi được cố tình chung chung vì tôi không muốn mạo hiểm sự thiên vị của chính mình. Vẫn thất vọng khi không nhận được câu trả lời dựa trên kinh nghiệm, nhưng đây là lý do được suy nghĩ tốt nhất nên cảm ơn.
pdr

4

Một trường hợp duy nhất là hành vi mặc định của Spring vì một lý do - một trường hợp duy nhất của dịch vụ phi trạng thái sẽ tiêu tốn ít tài nguyên hơn mà việc tạo và thu gom rác liên tục của nhiều trường hợp. Hơn nữa, không có mối nguy hiểm thực sự trong việc chia sẻ một dịch vụ phi trạng thái, nhưng có một số vấn đề về khả năng mở rộng thực sự với việc tạo ra nhiều phiên bản của một dịch vụ.

Vì vậy, tôi muốn nói rằng trường hợp đơn lẻ rất có thể sẽ là bạn của bạn.


0

Không có bối cảnh xa hơn, tôi nghĩ nó không thực sự quan trọng.

Bạn có thể nhận được lợi ích của các đối tượng tồn tại ngắn từ một thể hiện, nếu trường hợp đó chỉ đơn giản tạo các đối tượng tồn tại ngắn cho mỗi cuộc gọi và bạn có thể nhận được lợi ích của một đối tượng từ nhiều đối tượng tồn tại ngắn, nếu những đối tượng đó chỉ hành động như bánh đà .

Tất nhiên, nó ồn ào không cần thiết để thiết lập nó theo một cách, chỉ để giao phó cho người đối diện. Vì vậy, tôi đoán bạn chỉ nên đoán, liệu bạn có khả năng thêm trạng thái hay không, và nếu vậy, liệu nó sẽ ở trạng thái toàn cầu / liên tục (ví dụ như khi thêm bộ đệm) hoặc trạng thái tồn tại ngắn / cục bộ.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.