Có gì sai khi sử dụng một khung công tác có nhiều phụ thuộc?

Question

Gần đây tôi đã nói với một người bạn rằng tôi đã bắt đầu học Catalyst (Perl) và anh ấy nhấn mạnh rằng bởi vì chất xúc tác có rất nhiều phụ thuộc, nên tôi nên sử dụng thứ gì đó như Rails.

Đó không phải là một điều tốt mà có rất nhiều phụ thuộc? Điều đó không cho thấy rất nhiều mã tái sử dụng? Tôi hiểu rằng có thể có nhiều nỗ lực hơn trong việc cài đặt khung công tác nhưng có bất kỳ nhược điểm nào khác không?

Tôi sẽ tiếp tục Catalyst tutorial của mình cho đến khi tôi nhận được một số câu trả lời ngon miệng. :-)

Answer 1

Khi có sự phụ thuộc phiên bản giữa các thành phần, bạn có thể tự mình gặp phải tình huống không hoạt động nếu bạn buộc phải nâng cấp một thành phần (vì lý do bảo mật) trước phiên bản tương thích của thành phần phụ thuộc có sẵn.

Điều đó giả định bạn có thể vào trạng thái hoạt động ngay từ đầu. Nó có thể là nếu bạn cố gắng sử dụng các phiên bản hiện tại của tất cả các phụ thuộc, bạn sẽ thấy rằng họ không chơi cùng.

Số lượng phụ thuộc càng lớn thì rủi ro càng lớn.

Rails cũng không phải là vấn đề này. Với mỗi bản phát hành Ruby mới, có một cuộc tranh giành để cập nhật hướng dẫn về cách tải xuống trình điều khiển cơ sở dữ liệu.

Để công bằng, vấn đề này có xu hướng hướng tới "tốt hơn" theo thời gian, mặc dù có những va chạm trên đường.

Answer 2

Trải nghiệm cá nhân của tôi là bạn càng có nhiều phụ thuộc, bạn càng phải theo dõi phiên bản và điều này có thể dẫn đến các tình huống ác mộng. Đặc biệt, việc cập nhật một phụ thuộc (do lỗi bạn muốn sửa), ví dụ) có thể mang lại cho bạn các vấn đề tương thích với các phụ thuộc khác. Ví dụ, cá nhân tôi đã có một tình huống mà gcc 4.0.3 làm việc với foo nhưng không phải với thanh (phụ thuộc của foo), và gcc 4.0.5 làm việc với thanh nhưng không phải với foo. May mắn thay, 4.0.2 đã làm việc.

Ngoài ra, nhiều phụ thuộc hơn có xu hướng chỉ ra các sản phẩm "quái vật của Frankenstein", được làm từ các bộ phận không được thiết kế trước để chơi cùng nhau. Một khuôn khổ tích hợp tốt được thiết kế để chơi tốt đẹp và nhất quán. Điều này, tất nhiên, có thể được cố định bằng cách gói đúng sự khác biệt.

Answer 3

Không có gì đặc biệt sai với điều này. Ưu điểm của Catalyst là các phần của nó có thể được sử dụng bởi những người không sử dụng tất cả các chất xúc tác. Điều này có nghĩa rằng có nhiều mắt nhìn vào, và sửa lỗi trong, các phần quan trọng.

Khiếu nại lớn nhất mà tôi nghe nói là nó gây phiền toái khi xem tất cả các tin nhắn đó trong vỏ CPAN khi Catalyst đang cài đặt. Giải pháp là tận dụng lợi thế của trình quản lý gói của hệ điều hành của bạn khi bạn bắt đầu. Trên Debian, apt-get install libcatalyst-perl mất 15 giây để cài đặt trên máy không cài đặt mô-đun Perl khác. 15 giây. (Một cài đặt CPAN đơn giản cũng không khó, nhưng tôi đoán vỏ CPAN tiêu chuẩn hỏi bạn rất nhiều câu hỏi ngớ ngẩn, và điều đó đặt ra những người mới.)

Đừng lo lắng về sự phụ thuộc, có những công cụ tốt cho quản lý chúng, và chúng làm cho khung công tác mạnh mẽ và linh hoạt hơn.

Answer 4

Đây là chủ đề mà tôi đã xem bài đăng trước đây. Tôi đã có ý nghĩa để viết một bài báo về nó và cuối cùng đã làm như vậy.

Nó ở đây: The Lie of Independence

Tôi khuyến khích bạn đọc nó. Gist là đơn giản, mặc dù. Câu hỏi là sai. Nó không phải là 'Bạn có sử dụng một ứng dụng hoặc khung công tác với nhiều phụ thuộc, hoặc một trong đó không có chúng?'

Đó là: 'Bạn có sử dụng ứng dụng hoặc khung công tác có nhiều phụ thuộc bên ngoài hay một ứng dụng cố gắng thực hiện tất cả nội bộ?'

Và câu hỏi tiếp theo là 'Bạn có thực sự có niềm tin rằng người hoặc người viết khuôn khổ này hiểu mọi sắc thái của từng chi tiết nhỏ bé của mọi công việc cần phải thực hiện để xử lý yêu cầu web không?'