Cải Tiến Kiến Trúc ERP Mã Nguồn Mở WebVella: Phần 2 - Tách Biệt và Tối Ưu Hóa
Trong bài viết trước, mình đã thực hiện việc xem xét và cải tiến một số hàm trong mã nguồn WebVella. Ở bài viết này, chúng ta sẽ thảo luận về một số khía cạnh quan trọng trong kiến trúc để cải thiện cấu trúc mã nguồn của dự án này.
Tách Biệt Siêu Controller
Khi nhìn vào file WebApiController, ta sẽ bị choáng ngợp bởi kích thước của nó lên tới 4.5k dòng. Tình huống này có thể bắt nguồn từ việc các tác giả gom tất cả các endpoint vào trong một file, nhằm mục đích quản lý dễ dàng hơn. Tuy nhiên, điều này tiềm ẩn nhiều bất lợi:
- Tạo phụ thuộc không cần thiết: Lifetime của controller là ScopedAsync, nghĩa là nó sẽ được khởi tạo và giải phóng cùng với vòng đời của một request. Một instance chỉ để gọi một action, nhưng với tất cả action được gom vào một file, việc khởi tạo dependency trở nên lãng phí và tốn kém.
- Rủi ro khi phát triển: Việc thêm mới hoặc thay đổi các chức năng có thể dẫn đến các lỗi không mong muốn khi phụ thuộc được thêm vào.
- Khó khăn trong việc đọc mã: Việc xử lý một file lớn rất khó khăn cho các developer, làm giảm sự tự tin khi chỉnh sửa.
Giải pháp là tách các khối nghiệp vụ thành các controller riêng biệt. May mắn thay, các action đã được nhóm lại theo chức năng, việc này sẽ không gặp khó khăn lớn.
Tối Ưu Hóa Dependency Injection
Trong controller hiện tại, một số dependency được inject vào, nhưng một số khác lại bị khởi tạo trực tiếp trong mã nguồn. Điều này có thể xuất phát từ việc các tác giả không muốn thay đổi mã hiện tại.
Dependency Injection (DI) là một phương pháp giúp ẩn đi chi tiết tạo dựng một instance. Việc thay đổi một dependency thường gặp khó khăn do các lớp phụ thuộc lẫn nhau. Sử dụng DI giúp loại bỏ những rắc rối này, chỉ cần chúng ta tập trung vào lợi ích mà dependency mang lại.
Để khắc phục vấn đề này, chúng ta cần đăng ký các dependency của controller với DI container và thực hiện inject chúng trong constructor của controller.
Cải Tiến Dependency Inversion
Hiện tại, các dependency được inject vào controller là các lớp thực (concrete classes). Điều này mang đến nhiều thách thức:
- Khó khăn trong việc mở rộng: Việc sửa đổi trực tiếp các class concrete có thể ảnh hưởng đến nhiều nơi trong mã nguồn mà chúng ta không thể kiểm soát.
- Vấn đề unit testing: Để viết unit test cho các class, chúng cần được cô lập. Phụ thuộc vào các class cụ thể khác sẽ cản trở quá trình này.
Để cải thiện, chúng ta nên tạo các interface cho các dependency và đăng ký chúng với DI container.
Giới Hạn Sử Dụng Hàm Static
Hàm static được sử dụng khá nhiều trong mã nguồn này, chẳng hạn như trong AuthService. Dường như OAuth được thêm vào sau này, với việc sử dụng hàm static để tránh việc viết mã một cách chính quy. Dù các hàm này có vẻ không gọi đến các dependency khác, nhưng việc sử dụng chúng tạo ra phụ thuộc cứng và có thể gây khó khăn trong việc bảo trì mã nguồn.
Các hàm static nên chỉ được dùng cho các thao tác tính toán không chứa logic nghiệp vụ và không gọi đến bất kỳ dependency nào khác. Chúng ta sẽ cần chuyển đổi các hàm static này sang hàm thông thường để làm giảm bớt phụ thuộc.
Kết Luận
Việc cải tiến cấu trúc và kiến trúc mã nguồn là rất cần thiết nhưng cũng đầy thách thức. Các lớp có sự liên kết chặt chẽ gây khó khăn cho việc thay đổi, sửa đổi ở một class có thể dẫn đến hiệu ứng dây chuyền đến nhiều class khác. Tuy nhiên, việc chủ động cải tạo mã nguồn sẽ mang lại hiệu quả hơn nhiều so với việc phải xử lý các vấn đề phát sinh trong tương lai. Hãy bắt đầu tối ưu hóa mã nguồn ngay hôm nay để đơn giản hóa quy trình phát triển!
source: viblo
