Làm thế nào để tránh cơn ác mộng chuỗi phụ thuộc mô-đun gây ra bởi phụ thuộc bắc cầu?


9

Nhiều người (hầu hết?) AngularJS dường như ủng hộ việc phá vỡ các ứng dụng AngularJS thành nhiều mô-đun.

Brian Ford trong blog của mình đã tuyên bố rằng việc đóng gói theo lớp (bộ điều khiển, dịch vụ, v.v.) là một khái niệm "ngớ ngẩn", vì vậy tôi thậm chí sẽ không đến đó. (Xem http://briantford.com/blog/huuuuuge-angular-apps .)

Nhưng hãy giả sử rằng bạn mô đun hóa một ứng dụng theo tính năng. Có lẽ bạn có một mô-đun người dùng và mô-đun tin nhắn , cùng với mô-đun ứng dụng tiêu chuẩn để tải các mô-đun tính năng này. Bạn chu đáo đặt các tuyến liên quan đến chức năng người dùng trong mô-đun người dùng và các tuyến liên quan đến tin nhắn trong mô-đun tin nhắn . Bây giờ, trong tâm trí của tôi, bạn đã tạo ra một phụ thuộc trong mô-đun tính năng EACH trên ngRoute . Vì vậy, mỗi mô-đun nên liệt kê "ngRoute" trong mảng phụ thuộc của nó, phải không?

Thật không may, AngularJS làm cho tất cả quá dễ dàng để làm hỏng nó. Nếu mô-đun ứng dụng của bạn tải cả người dùngtin nhắn , nhưng chỉ người dùng liệt kê "ngRoute" là phụ thuộc, thì không vấn đề gì trong thời gian chạy: $ routeProvider vẫn sẽ được đưa vào chức năng cấu hình của bạn trong tin nhắn , về cơ bản đã được giải quyết thông qua mô-đun người dùng phụ thuộc vào ngRoute .

Vấn đề của tôi có thể là với mô hình chung của mô-đun "ứng dụng" đang tải / tham chiếu các mô-đun tính năng khác nhau. Các mô hình có ý nghĩa với tôi, cũng như phụ thuộc bắc cầu. Vấn đề là việc triển khai cụ thể của Angular có thể che giấu các trường hợp trong đó một mô-đun không tham chiếu các phụ thuộc mô-đun của nó thậm chí gián tiếp. Mô-đun có thể hoạt động trong ngữ cảnh của một ứng dụng cụ thể (vì mô-đun được tham chiếu bởi mô-đun "ứng dụng" khác cũng xảy ra để tham chiếu phụ thuộc trực tiếp hoặc gián tiếp), nhưng nếu bạn sao chép mô-đun vào ứng dụng khác, nó sẽ thất bại do thiếu phụ thuộc.

Tôi có ấn tượng rằng hầu hết mọi người sẽ không cân nhắc nhiều đến thực tế là mô-đun người dùng hiện nay về cơ bản là sự phụ thuộc của mô-đun tin nhắn . Tuy nhiên, đó là một vấn đề tôi gặp khó khăn khi nhìn qua. Đối với tôi, nếu chúng ta có khả năng tạo ra những phụ thuộc khó hiểu này giữa các mô-đun tính năng, thì nó thực sự làm giảm lợi ích ròng của việc mô đun hóa, và tôi chỉ muốn có một mô-đun ứng dụng duy nhất gói gọn tất cả các thành phần cho tất cả các tính năng trong ứng dụng.


Ngoài ra, các phụ thuộc bắc cầu không phải là một tạo tác kỳ lạ được giới thiệu bởi một triển khai kỳ lạ, thực sự có các phụ thuộc và chúng thực sự mang tính bắc cầu. Chúng cũng phổ biến trong lập trình. Tôi không chắc tại sao nó khó hiểu hay một cơn ác mộng. Có lẽ bạn có thể giải thích tại sao đây là điều cần quan tâm?
psr

Câu trả lời:


1

Tôi sẽ không ủng hộ nhiều mô-đun nhỏ, lợi ích của họ là quá nhỏ. Các mô-đun góc thực sự không nhiều của một hệ thống mô-đun. Chúng không cung cấp không gian tên thực, chúng cũng không nghiêm ngặt, nếu một số mô-đun hoạt động khác 'nhập' sự phụ thuộc của bạn, nó sẽ thường hoạt động (như bạn đã đề cập), v.v. sẽ không đầy đủ

Chỉ cần dính vào các mô-đun rất thô / lớn. Tôi đã học cách chủ yếu xem chúng như một cấu hình thùng chứa phụ thuộc không phải là một phương tiện để 'thành phần hóa'. Dù sao, tất cả các 'mô-đun' này thường vi phạm YAGNI, như thể bạn đã từng chạy ứng dụng mà không có. Xem xét tái sử dụng chủ yếu là một lời hứa mà hiếm khi cung cấp.

Ngày nay tôi sử dụng các mô-đun của TypeScript để phân vùng mã của mình. Phụ thuộc mô-đun góc Tôi phần lớn dự trữ cho công cụ bên thứ 3 thực sự.

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.