Framework đang trở nên khá phổ biến. Nhìn chung thì đó là một điều tốt. Có rất nhiều framework ngoài kia miễn phí, mạnh mẽ, và hữu ích.

Tuy nhiên, các framework không phải là kiến trúc – mặc dù một số cố gắng để được coi như vậy.

Các tác giả framework

Phần lớn các tác giả framework miễn phí sản phẩm của họ bởi vì họ muốn được trở nên có ích với cộng đồng. Họ muốn đóng góp cho cộng đồng. Đây là một điều đáng ca ngợi. Tuy nhiên, dù cho động cơ của họ có cao cả thế nào đi nữa thì những tác giả này trong lòng cũng không có được những mong muốn nhất của bạn. Họ không thể, bởi vì họ không biết bạn, và họ không biết các vấn đề của bạn.

Các tác giả framework biết các vấn đề của chính họ, và các vấn đề của đồng nghiệp và bạn bè của họ. Và họ viết các framework đó để giải quyết những vấn đề đó – không phải của bạn.

Dĩ nhiên, các vấn đề của bạn sẽ trùng với một số vấn đề đó một chút. Nếu điều này không xảy ra thì các framework đó đã không phổ biến như vậy. Khi mở rộng phạm vi giải quyết vấn đề, thì quả thực các framework đó có thể rất hữu ích.

Hôn nhân không tương xứng

Mối quan hệ giữa bạn và tác giả framework không tương xứng một cách lạ thường. Bạn phải cam kết rất lớn đối với framework, nhưng tác giả framework thì không cam kết với bạn bất cứ điều gì.

Hãy nghĩ về điểm này một cách cẩn thận. Khi bạn dùng một framework, bạn đọc qua tài liệu mà tác giả của framework đó cung cấp. Trong tài liệu đó, tác giả và những người dùng của framework đó, khuyên bạn cách tích hợp phần mềm của bạn với framework đó. Thông thường, điều này có nghĩa là việc gói kiến trúc của bạn xung quanh framework. Tác giả đó khuyên bạn kế thừa các lớp cơ sở của framework, và cho các tiện ích của framework vào trong các đối tượng nghiệp vụ của bạn. Tác giả đó hối thúc bạn gắn kết ứng dụng của bạn vào framework đó càng chặt càng tốt.

Đối với tác giả framework, việc gắn kết với framework của anh ấy hoặc cô ấy thì không mạo hiểm chút nào. Tác giả đó muốn gắn kết với framework đó, bởi vì họ có quyền kiểm soát tuyệt đối với framework đó.

Hơn nữa, họ lại muốn bạn gắn kết với framework đó, bởi vì một khi đã gắn kết theo cách này, sẽ rất khó để phá vỡ nó được. Không gì cảm thấy tự tin hơn đối với một tác giả framework khi một nhóm người dùng sẵn sàng kế thừa chặt chẽ từ các lớp cơ sở của tác giả đó.

Trên thực tế, tác giả đó đang đề nghị bạn kết hôn với framework của họ – đưa ra một cam kết lớn, dài hạn với framework đó. Chưa hết, trong mọi trường hợp, tác giả đó sẽ không đưa ra cam kết tương ứng đối với bạn. Đó là một cuộc hôn nhân một chiều. Bạn sẽ chịu mọi rủi ro và gánh nặng; tác giả framework thì không phải chấp nhận điều gì cả.

Mối nguy hiểm

Mối nguy hiểm ở đây là gì? Ở đây chỉ có một vài điều mà bạn nên cân nhắc.

• Kiến trúc của framework thường rất không tinh gọn. Các framework có khuynh hướng vi phạm Quy Tắc Phụ Thuộc. Họ yêu cầu bạn kế thừa code của họ trong các đối tượng nghiệp vụ của bạn – các Entity của bạn! Họ muốn framework của họ gắn kết với vòng tròn trong cùng đó. Một khi đã vào trong, framework đó sẽ không quay trở ra nữa. Chiếc nhẫn cưới sẽ trên ngón tay của bạn; và nó sẽ tiếp tục ở đó.
• Framework có thể giúp bạn với một số chức năng ban đầu của ứng dụng của bạn. Tuy nhiên, khi sản phẩm của bạn trưởng thành, nó có thể sẽ cần nhiều hơn những tiện ích của framework đó. Nếu bạn đã đeo chiếc nhẫn cưới đó, bạn sẽ thấy framework đó vả vào mặt bạn ngày càng nhiều khi thời gian trôi qua.
• Framework có thể được phát triển theo hướng mà bạn cảm thấy không hữu ích nữa. Bạn có thể bị bế tắc khi việc nâng cấp lên phiên bản mới cũng không giúp gì cho bạn. Bạn thậm chí có thể thấy các chức năng cũ khác, mà bạn đã dùng bị biến mất hoặc bị thay đổi theo cách khó cho bạn để bám theo.
• Một framework mới và tốt hơn có thể xuất hiện và bạn ước rằng bạn có thể chuyển sang framework đó.

Giải pháp

Vậy giải pháp là gì?

Đừng kết hôn với framework!

Ồ, bạn có thể sử dụng framework – chỉ là đừng gắn kết với nó. Hãy giữ nó ở khoảng cách chừng mực. Hãy đối xử với framework đó như là một chi tiết thuộc về một trong những vòng tròn ngoài cùng của kiến trúc của bạn. Đừng để nó đi vào các vòng tròn bên trong.

Nếu framework muốn bạn kế thừa các đối tượng nghiệp vụ của bạn từ các lớp cơ sở của nó, hãy nói không! Thay vào đó hãy kế thừa các trung gian (proxy), và để cho những trung gian đó trong các component là plugin của các quy tắc nghiệp vụ của bạn.

Đừng để framework đi vào phần code cốt lõi của bạn. Thay vào đó, tích hợp chúng trong các component “cắm vào” phần code cốt lõi của bạn, tuân theo Quy Tắc Phụ Thuộc.

Lấy ví dụ, có thể bạn thích Spring. Spring là một framework chèn phụ thuộc (dependency injection) tốt. Có thể bạn dùng Spring để auto-wire (tự động móc nối) các phụ thuộc của bạn. Điều đó tốt, nhưng bạn không nên gieo rắc chú giải @autowired mọi nơi trong các đối tượng nghiệp vụ của bạn. Các đối tượng nghiệp vụ của bạn không nên biết gì về Spring.

Thay vào đó, bạn có thể dùng Spring để chèn các phụ thuộc vào trong Main component của bạn. Việc cho phép Main biết về Spring thì OK bởi vì như bạn đã biết Main là component cấp thấp nhất, bẩn nhất trong kiến trúc.

Bây giờ tôi thông báo với bạn…

Có một vài framework mà bạn đơn giản buộc phải kết hôn với nó. Lấy ví dụ, nếu bạn đang dùng C++, bạn sẽ phải cưới STL – khó mà tránh được. Nếu bạn dùng Java, bạn hầu như sẽ chắc chắn phải cưới các thư viện tiêu chuẩn.

Đó là điều bình thường – nhưng nó vẫn phải là một quyết định. Bạn phải hiểu khi nào bạn cưới một framework cho ứng dụng của bạn, bạn sẽ bị mắc kẹt với framework đó cho toàn bộ vòng đời của ứng dụng đó. Dù có tốt hơn hay tệ hơn, dù ốm đau hay khỏe mạnh, dù giàu hơn hay nghèo hơn, bỏ qua tất cả, bạn sẽ sử dụng framework đó. Đây không phải là một cam kết được thực hiện một cách nhẹ nhàng.

Kết luận

Khi đối mặt với một framework, bạn hãy cố gắng đừng cưới nó ngay lập tức. Hãy xem có cách nào hẹn hò với nó một thời gian trước khi bạn đâm đầu vào. Hãy giữ cho framework đó ở phía sau ranh giới kiến trúc của bạn nếu có thể, càng lâu càng tốt. Có lẽ bạn có thể tìm được cách để lấy sữa mà không phải mua bò.