NộI Dung
Hãy hỏi tôi nên sử dụng khuôn khổ nào và tôi có thể sẽ có một khoảnh khắc bà già khó tính và nói với bạn rằng tất cả các khuôn khổ đều tệ như nhau. Điều đó không có nghĩa là tất cả chúng đều tệ, chính xác, nhưng trong PHP, chúng ta có một số lượng lớn không thể tưởng tượng được (thường được gọi là N + 1, trong đó N là số lượng nhà phát triển PHP trên thế giới), và tất cả chúng có lẽ đều có ý nghĩa cho người đã phát minh ra chúng.
Có sự lựa chọn khung có lẽ tốt hơn là cố gắng chỉ sử dụng một khung, bất kể chính xác bạn đang cố gắng xây dựng cái gì, bởi vì đó là cái 'tốt nhất' (theo bất kỳ thước đo nào của 'tốt nhất'). Việc lựa chọn các dịch vụ khung này có nghĩa là bạn có thể chọn một thứ gì đó đáp ứng nhu cầu của dự án và thậm chí nó có thể được lập thành văn bản. Các khung công tác trên bất kỳ nền tảng nào thực sự ở đó để cung cấp cấu trúc, các mô-đun và thư viện có thể tái sử dụng và nói chung tránh tất cả các tác vụ nhàm chán và lặp đi lặp lại liên quan đến việc xây dựng cùng một chức năng. Ví dụ: khi xây dựng CMS, một cái gì đó sẽ xử lý và xác thực các trường biểu mẫu cho tôi; nếu để các thiết bị của riêng mình, tôi có thể bỏ lỡ điều gì đó quan trọng và tôi muốn thực hiện các yếu tố của mỗi dự án khác nhau, thay vì những cái giống nhau mọi lúc!
Các khuôn khổ toàn ngăn xếp
Các khung công tác full-stack, chẳng hạn như Zend Framework, có thể là một nơi tốt để bắt đầu cho một nhà phát triển không có nhiều kinh nghiệm về kiến trúc. Nó cung cấp cấu trúc tốt để treo một ứng dụng mới và có một 'hệ sinh thái' tốt xung quanh nó - rất nhiều sách, hướng dẫn và một số tài liệu hợp lý nữa. Nếu bạn đang cố gắng xây dựng một ứng dụng lớn sẽ được nhiều người duy trì, thì một khuôn khổ phổ biến, toàn diện có thể là một lựa chọn tốt vì nó sẽ quy định khá nhiều cấu trúc và được nhiều người biết đến và hiểu rõ.
Có cấu trúc để giúp tách biệt luôn luôn tốt; ngay từ đầu trong sự nghiệp của mình, tôi đã làm việc với một số rất các nhà phát triển cơ sở và cố gắng dạy họ mẫu MVC (Model View Controller), mẫu này còn tương đối mới vào thời điểm đó. Chúng tôi đã quyết định sử dụng Smarty trong lớp xem; một phần để các nhà thiết kế có thể làm việc với các mẫu dễ dàng hơn, và một phần để khi ai đó đến bàn của tôi và nói "làm cách nào để làm X với Smarty?" Tôi có thể nói "đừng làm X trong chế độ xem!" (chín lần trong số 10, đó là câu trả lời). Có các khuôn khổ giúp chúng tôi tìm thấy sự tách biệt tương tự trong các phần khác của ứng dụng của chúng tôi. Nhiều người trong số họ hỗ trợ tích hợp với một lớp tạo khuôn mẫu chẳng hạn như Smarty hoặc yêu thích mới của tôi, Twig, vì vậy bạn có thể mang theo những công cụ đó cho dù bạn chọn khuôn khổ nào.
Làm giảm tải
Có rất nhiều framework nhẹ hơn Zend Framework, ví dụ như tôi làm việc với CodeIgniter khá nhiều. Nó có toàn diện và mạnh mẽ như Zend Framework không? Không, không phải vậy. Nhưng với tư cách là một khung trợ giúp để cho phép xây dựng một ứng dụng nhanh chóng, nó rất hữu ích. Nói chung, các khuôn khổ có ít chức năng 'trợ giúp' hơn có thể dễ dàng tìm thấy hướng đi của bạn hơn vì cách các phần kết hợp với nhau rõ ràng hơn nhiều. Trong một khuôn khổ không quen thuộc (đối với tôi, đó là hầu hết mọi thứ), đó là các bit tự động hóa khiến việc xử lý và gỡ lỗi trở nên khó khăn.
Cảm giác “lạc vào một khuôn khổ mới” đó là điều khó tránh khỏi và hoàn toàn bực bội; ngay cả một nhà phát triển có kinh nghiệm cũng cảm thấy như một người mới khi họ không biết cách hoạt động của bất kỳ thứ gì. Nếu bạn thực sự không may mắn, bạn sẽ chọn được một khuôn khổ mà kênh IRC sẽ cho bạn biết rằng bạn cũng là một tên ngốc! Chính trải nghiệm ban đầu rất tiêu cực này khiến nhiều người không thích sử dụng một khuôn khổ mới hoặc áp dụng một khuôn khổ mới ngay từ đầu và rất ít khuôn khổ làm tốt công việc giúp đỡ người dùng mới vượt qua rào cản ban đầu đó.
Trong PHP, chúng tôi cũng có một số khuôn khổ không thực sự là khuôn khổ theo cách mà tôi thường sử dụng từ này. Chúng tôi có một số khuôn khổ thành phần đáng yêu; bộ sưu tập các thư viện được thiết kế để sử dụng theo ý muốn và kết hợp độc đáo với nhau, chẳng hạn như Thành phần Zeta (trước đây là Thành phần eZ) và Thành phần Symfony (bạn đã xem trang web của họ chưa? Họ giành được giải thưởng cho tác phẩm nghệ thuật hay nhất!). Tất nhiên, điều tốt nhất và nổi bật nhất trong số này là các dịch vụ PEAR và PECL của chính PHP - bằng cách nào đó chúng bị lãng quên trong thế giới khuôn khổ mới đầy dũng cảm này.
Microframeworks
Microframeworks là một xu hướng mới nổi trong PHP; đây là những sản phẩm siêu nhẹ chỉ giúp bạn gắn kết mọi thứ với nhau nhanh chóng hơn. Một ví dụ điển hình là Slim, sử dụng rất nhanh và đơn giản, đồng thời hiểu được các khái niệm RESTful. Nó dựa trên ý tưởng về 'các tuyến đường', là các mẫu URL. Bạn đăng ký một tuyến đường và đưa ra một cuộc gọi lại sẽ được gọi khi URL đó được yêu cầu.
Hầu hết các nhà phát triển PHP áp dụng một khuôn khổ và gắn bó với nó, hoặc họ có thể sử dụng một khuôn khổ tại nơi làm việc và một khuôn khổ khác cho sở thích hoặc các dự án nguồn mở của họ. Có rất ít sự đồng thuận về khuôn khổ "tốt nhất" để sử dụng, vì vậy mọi người chỉ bám vào những gì họ biết và kết quả là sự phát triển song song của số lượng lớn các khuôn khổ! Tôi thích có một lựa chọn để lựa chọn, nhưng tôi đã đề cập rằng tất cả chúng đều tệ như nhau?
Nếu bạn biết Zend Framework thì bạn sẽ tự mô tả mình là một nhà phát triển Zend Framework; bạn sẽ không thấy thoải mái khi viết trong một khuôn khổ khác cho đến khi bạn có cơ hội nắm bắt được nó và có thể bạn không nhớ nhiều hàm PHP thô cho mọi thứ nếu bạn không sử dụng chúng thường xuyên. Ý tưởng rằng chúng tôi đã trở thành nhà phát triển khung cụ thể, chỉ làm việc trên các lớp trừu tượng, hơi lạ đối với PHP. Sau khi tất cả, đây là ngôn ngữ "để giải quyết vấn đề web". Nó được viết bằng C và bản thân nó là một ngôn ngữ nhanh, nhẹ ... với điều kiện là bạn không cần đợi quá trình khởi động khuôn khổ lớn chạy! Từ bối cảnh này đã xuất hiện Tuyên ngôn MicroPHP, được viết bởi một người đàn ông mà chúng tôi gọi là Funkatron (mặc dù tên của anh ta thực sự là Ed Finkler). Một loạt các tuyên bố nói rằng có thể xây dựng một số mô-đun nhỏ có thể tương tác được, còn mô-đun lớn hơn thì không tốt hơn và thực sự, cuộc sống của Java quá ngắn - ngay cả khi nó được viết bằng PHP.
