Trong cộng đồng Java có một cơn sốt về các container nhỏ gọn giúp lắp ráp các thành phần từ các dự án khác nhau vào một ứng dụng thống nhất. Đằng sau những container này là một mô hình khá phổ biến là làm thế nào họ thực hiện các kết nối giữa các hệ thống, một khái niệm mà họ gọi dưới cái tên rất chung chung đó là “Inversion of Control”. Trong bài viết này, tôi đi sâu vào mô hình này xem chúng hoạt động thế nào dưới cái tên cụ thể hơn là “Dependency Injection”, và ngược lại nó với sự thay thế của Service Locator. Sự lựa chọn giữa chúng ít quan trọng hơn so với các nguyên tắc tách cấu hình của chúng ra khỏi Use.
Một trong những điều thú vị về thế giới doanh nghiệp Java là số tiền rất lớn phải chi trả cho các hoạt động trong xây dựng thay thế cho công nghệ chủ đạo J2EE, điều này xảy ra khá nhiều ở mã nguồn mở. Trong số đó, có rất nhiều phản hồi về sự phức tạp nặng nề trong thế giới J2EE chính thống, nhưng có khá nhiều vấn đề cũng được khám phá giải pháp thay thế và mở đầu cho những ý tưởng sáng tạo. Một trong những vấn đề phổ biến để giải quyết là làm thế nào để kết nối các yếu tố khác nhau lại: làm thế nào để bạn có làm cho kiến trúc điều khiển trang web này phù hợp với giao diện cơ sở dữ liệu khi nó được xây dựng bởi các đội lập trình khác nhau và không nắm được ý của nhau. Một số framework đã mắc phải vấn đề này, và một số được phân nhánh để cung cấp khả năng tổng hợp để lắp ráp các thành phần từ các lớp khác nhau. Chúng thường được gọi là các Container nhỏ gọn, ví dụ bao gồm PicoContainer, và Spring.
Đằng sau những Container là một số nguyên tắc thiết kế thú vị, những thứ đi xa hơn cả những container cụ thể này và thực sự là nền tảng của Java. Ở đây, tôi muốn bắt đầu khám phá một số nguyên tắc này. Các ví dụ tôi sử dụng là của Java, nhưng cũng giống như hầu hết các văn bản của tôi, các nguyên tắc đều như nhau đối với các môi trường OO khác, đặc biệt là .NET.
Các thành phần và dịch vụ
Chủ đề hệ thống kết nối của các yếu tố kéo tôi gần như ngay lập tức vào các vấn đề thuật ngữ có nhiều rắc rối xung quanh các điều khoản dịch vụ và thành phần của chúng. Bạn sẽ dễ dàng tìm thấy các bài viết dài và trái ngược nhau về định nghĩa của những điều này. Đối với mục đích của tôi, có quá nhiều điều kiện hiện tại tôi đang sử dụng.
Tôi sử dụng thành phần để định nghĩa một khối phần mềm dự định sẽ được sử dụng mà không có sự thay đổi, bởi một ứng dụng vượt khỏi sự kiểm soát của các tác giả của các thành phần đó. Từ ‘không thay đổi’ có nghĩa là các ứng dụng mà tôi sử dụng không hề thay đổi mã nguồn của các thành phần, mặc dù họ có thể thay đổi hoạt động của các thành phần bằng cách mở rộng nó bằng nhiều cách cho phép bởi những nhà lập trình các thành phần đó.
Một dịch vụ tương tự như một thành phần trong đó được sử dụng bởi các ứng dụng nước ngoài. Sự khác biệt chính là việc tôi mong đợi thành phần này được sử dụng tại nội vùng (hãy nghĩ đến file jar, lắp ráp, dll, hoặc các nguồn nhập). Một dịch vụ sẽ được sử dụng từ xa thông qua một số giao diện từ xa, 1 trong 2 đồng bộ hoặc không đồng bộ (ví dụ như dịch vụ web, hệ thống tin nhắn, RPC, hoặc ổ cắm.)
Tôi chủ yếu sử dụng dịch vụ trong bài viết này, nhưng nhiều của logic tương tự cũng có thể được áp dụng cho các thành phần địa nội vùng. Thật vậy, bạn thường xuyên cần một số loại framework thành phần nội vùng để dễ dàng truy cập vào một dịch vụ từ xa. Nhưng cứ viết “thành phần hoặc dịch vụ” thì đọc và viết thật là mệt mỏi, và các dịch vụ thì lại rất phổ biến tại thời điểm hiện tại…
(còn tiếp…)