Vì sao các PHP framework làm cho ứng dụng của bạn nặng nề hơn?

Lang thang được bài viết khá hay của bác Huy 🙂

Nếu bạn đã từng làm việc với các PHP framework như symfony, Cake, Zend … có thể bạn đã nhận ra những vấn đề này. Tôi xin nêu ra đây cả cách giải quyết của mình.

Việc sử dụng các pattern như Active Record, Data Mapping để làm Model trong các framework là một ác mộng.

Thật vậy, không những làm bạn khó khăn hơn trong việc xoay sở với SQL, nó còn khiến quá trình truy xuất dữ liệu trở nên nặng nề hơn. Các pattern này quy mỗi record trong database thành một object. Việc làm này là cực kỳ không cần thiết. Không phải lúc nào bạn cũng select chúng ra sau đó lại update trở lại database. Những logic nhằm bảo đảm mối quan hệ giữa các object cũng ngốn kha khá tài nguyên. Hơn nữa, các câu SQL được tự động sinh ra sẽ không đạt được mức độ tối ưu như mong muốn. Tối ưu SQL là một công việc quan trọng nhưng các ORM lại cố ngăn bạn khỏi công việc đó.

Giải pháp của tôi

Sử dụng DAO pattern để thay cho Active Record. Hoặc tốt hơn nữa là sử dụng các tính năng được hỗ trợ sẵn trong hệ quản trị cơ sở dữ liệu mà lâu nay lập trình viên PHP/(nhất là MySQL) thường quên đi mất như View, Trigger, Stored Procedured…  Bạn không nên lo ngại việc các lập trình viên của mình phải viết SQL. Suy cho cùng họ là lập trình viên, công việc của họ là viết code.

Lạm dụng sự tự động hoá.

Các framework thường tự động hoá một số giai đoạn trong workflow để trở nên thân thiện hơn đối với developer. Nếu bạn đã dùng qua CakePHP, bạn sẽ hiểu. Cake cho phép bạn khai báo các model và component bạn cần trong controller và tự động load toàn bộ chúng trong quá trình start-up. Điều này làm cho ứng dụng phải mất rất lâu để start-up. Hơn nữa, với cách phân chia ứng dung thành controller/action, bạn gặp phải một vấn đề là không phải lúc nào bạn cũng cần những model/component giống nhau ở tất cả các action trong cùng một controller. Với cách làm của CakePHP, bạn phải load những thứ mình không cần một cách bất đắc dĩ.

Giải pháp của tôi

Dẹp sự tự động hoá sang một bên đi! Hiện đại là hại điện. Tôi nhắc lại một lần nữa, bạn tuyển những lập trình viên và trả lương cho họ để họ viết code. Đừng ngại khi bắt họ làm chuyện đó.

Chính mô hình MVC làm tăng thêm các giai đoạn trong workflow của bạn

Ok, MVC là một mô hình tốt, chẳng ai phủ nhận cả. Nhưng việc phân chia rạch ròi giữa business logic (M) và presentation logic (V) cũng làm cho mọi thứ trở nên rắc rối hơn. Một ví dụ: trong mô hình MVC mà bạn gặp ở các framework mà tôi kể ở trên, Model thường xử lý dữ liệu xong rồi truyền cho View. Giả sử ở đây bạn có một list các bài hát cần in ra. Cách thông thường nhất và gần như duy nhất mà ta thường làm là Model nhận việc select từ database, duyệt qua tập kết quả lần để để tổng hợp nó thành một danh sách (ở PHP thì rất có thể là mảng) rồi sau đó mới truyền cho View. View lại phải duyệt qua mảng đó thêm một lần nữa để in ra.

Giải pháp của tôi

Tôi không có cách giải quyết nào và chấp nhận vấn đề này ở hiện tại. Thật ra nó cũng không ảnh hưởng quá nhiều đến performance, bù lại ta có được sự tách biệt rạch ròi về kiến trúc.

OOP

Lập trình OOP luôn luôn ngốn nhiều tài nguyên hơn so với function-based. Thêm vào đó, với đặc điểm của PHP, việc viết mỗi lớp thành một file riêng sẽ làm phân mảnh code và buộc PHP engine phải làm việc nặng nề hơn (nhất là đối với các framework như Zend).

Giải pháp của tôi

Sử dụng các opcode caching egine như APC, XCache.

Nguồn: byhuy.com