Tái cấu trúc Controller và Actions trong thực tế

Khi phát triển một ứng dụng web application theo mô hình MVC, các nhà phát triển trong một tổ chức thường tự mình đặt tên cho controller và actions. Điều này sẽ dẫn đến khó có thể hiểu được action trong controller đó làm việc gì nếu như đặt tên không chính xác. Thực chất, việc đặt tên các controllers và các actions trong controllers đó là một bài toán không đơn giản do làm thế nào để đặt tên actions ngắn gọn, dễ nhớ và dễ tìm kiếm khi ứng dụng có xu hướng mở rộng. Trong ứng dụng nhỏ có thể không cần theo cách áp dụng này; tuy nhiên khi dự án có xu hướng mở rộng và phát triển lâu dài thì vấn đề đặt tên controller và actions theo chuẩn sẽ giúp quá trình phát triển nhanh hơn và dễ bảo trì hơn. Mời các bạn cùng tham khảo chi tiết nội dung bài viết!
Nội dung trích xuất từ tài liệu:
Tái cấu trúc Controller và Actions trong thực tế TÁI CẤU TRÚC CONTROLLER VÀ ACTIONS TRONG THỰC TẾ Nguyễn Hữu Cầm Trường Đại học Hà Nội Abstract: Khi phát triển một ứng dụng web application theo mô hình MVC, các nhà pháttriển trong một tổ chức thường tự mình đặt tên cho controller và actions. Điều này sẽ dẫn đếnkhó có thể hiểu được action trong controller đó làm việc gì nếu như đặt tên không chính xác.Thực chất, việc đặt tên các controllers và các actions trong controllers đó là một bài toán khôngđơn giản do làm thế nào để đặt tên actions ngắn gọn, dễ nhớ và dễ tìm kiếm khi ứng dụng cóxu hướng mở rộng. Trong ứng dụng nhỏ có thể không cần theo cách áp dụng này; tuy nhiênkhi dự án có xu hướng mở rộng và phát triển lâu dài thì vấn đề đặt tên controller và actions theochuẩn sẽ giúp quá trình phát triển nhanh hơn và dễ bảo trì hơn. Từ khoá: Action, Controller, Laravel, MVC architecture, Naming convention. A.Giới thiệu Trong một ứng dụng MVC, việc đặt tên cho controller và action là một bài toánđau đầu đối với các nhà lập trình viên. Sẽ có những lập trình viên khi lập trình một ứngdụng Laravel thường tạo controller rồi viết rất nhiều actions trong đó với chiều dài cóthể lên tới hàng trăm dòng code. Điều này sẽ gây khó k [23]hăn không chỉ với bản thânngười lập trình mà với những người duy trì dự án sau này khi đọc lại chính code củamình viết ra mà không hiểu tại sao mình lại viết như thế này cũng như mất thời gian đểtìm hiểu lại xem phương thức này có ý nghĩa là gì. Vì thế, việc tách controller cũng nhưactions trong controller đó thành các actions nhỏ hơn sẽ giúp quản lí hiệu quả khi dự ánngày một phức tạp hơn. B. Lý thuyết và ứng dụng Bản chất chính của method này là hãy tách nhỏ controller thành các method quychuẩn sauTên function Method type Chức năng Index() GET Xem danh sách resources tồn tại trong hệ thống: Ví dụ như xem danh sách users và danh sách roles, etc. Create() GET Xem trang create resource. Ví dụ như xem trang create user, create role Store() POST Tiến hành thêm mới resource vào hệ thống Edit() GET Xem trang edit resource Update() PUT|PATCH Tiến hành update resource vào hệ thống Delete() DELETE Tiến hành xoá resource trong hệ thống Show() GET Xem thông tin chi tiết resource nhất định trong hệ thống 200 Bài toán được ứng dụng như sau. Người dùng có xem danh sách podcasts, trongmỗi podcasts có nhiều episodes. Người dùng có thể xem danh sách episodes trong hệthống, subscribe/unsubscribe podcast nhất định, publish/unpublish podcast và thay đổicover image của podcasts trong hệ thống. Quy tắc 1: Tách nested resource thành controller riêng Ví dụ với vấn đề người dùng xem danh sách episodes trong podcast với URI theochuẩn RESTful như sau Figure 9: URI trước khi refactor route cho nested resource - Lựa chọn thứ nhất: Nếu để action ví dụ như listEpisodes() trongPodcastController thì sẽ bị vi phạm nguyên tắc 7 methods như đã đề cập ở trên sai nguyên tắc - Lựa chọn thứ 2: Nếu để method index() trong EpisodeController thìbản thân function này có ý nghĩa xem tất cả các episodes trong hệ thống  không chínhxác. - Lựa chọn thứ 3: Tách thành 1 controller riêng có tên làPodcastEpisodesController với method là index(). Route sẽ được biểudiễn như sau Figure 10: URI sau khi đã refactor nested resource trong route/web.php Trong code Figure 11: Code behind trong nested resourcevới $id là id của podcasts. 201Việc làm này còn có một ưu điểm khác, trong trường hợp nếu muốn tạo mới 1 episodetrong 1 podcasts nhất định thì URI sẽ như sau Figure 12: Different routing trong route/web.phpVới create() là xem trang thêm mới episode trong podcasts nhất định và store()dùng để tiến hành thêm mới episode trong podcasts.Với các lí do trên, lựa chọn 3 là lựa chọn tốt nhất để quản lí episodes trong podcasts.Quy tắc 2: Tách edited property thành 1 controller riêngBài toán tiếp theo cho phép người dùng thay đổi cover image của podcast nhất định Figure 13: Trước khi refactor route “Update cover image” trong route/web.phpCode Figure 14: Code behind edited propertyBản thân hàm updateCoverImage($id) ...