12. tháng 1 2025

Tuy nhiên, điểm hạn chế duy nhất là - choi game ban ca

/imgposts/927ddlpx.jpg

Trong công việc hàng ngày, tôi thường xuyên tải lên các ứng dụng Android đã phát triển lên máy chủ đám 789bey mây, sau đó chuyển đổi đường dẫn tải về thành mã QR và gửi cho khách hàng để họ quét mã và cài đặt dễ dàng. Trước đây, tôi đã sử dụng dịch vụ "Cao Liao QR Code" để đáp ứng nhu cầu này, nhưng quy trình hoạt động đôi khi hơi phức tạp. Vì vậy, tôi đã quyết định nhân dịp tự học .NET 8, vừa học vừa phát triển một công cụ tạo mã QR trực tuyến riêng. Đây cũng là cách để tìm niềm vui nhỏ trong những giờ làm việc nhàm chán.

Sau một tuần làm việc không liên tục, mỗi ngày chỉ khoảng nửa tiếng, cuối cùng tôi cũng hoàn thành và đưa công cụ lên mạng. Nhìn chung, trải nghiệm phát triển với ASP.NET Core MVC trong .NET 8 khá thoải mái. Tuy nhiên, tài liệu chính thức đôi khi bị phân tán và khó theo dõi, buộc phải tìm kiếm ở nhiều nơi khác nhau. Ngoài ra, hầu hết các cuốn sách trên thị trường đều thiếu tính hệ thống, phần lớn chỉ là bản sao lại từ tài liệu chính thức mà không có hướng dẫn chi tiết từng bước. Do đó, viết một khóa học cơ bản về .NET 8 chắc chắn sẽ rất hữu ích.

  • Tiếng Việt: Bộ tạo mã QR
  • Tiếng Anh: Qrcode Generator

Một trong những lý do lớn khiến tôi muốn thử nghiệm .NET 8 là vì trước đây, các khung công tác như golang gin và rust axum gần như không hỗ trợ quốc tế hóa (i18n). Tôi đã phải tự xây dựng giải pháp, ví dụ như cách tôi áp dụng i18n cho trang web đa ngôn ngữ dựa trên golang gin. Mặc dù tạm thời khả thi, nhưng trong các dự án thực tế, phương pháp này dần bộc lộ nhiều bất tiện. Ví dụ, khi số lượng tính năng tăng lên, tôi gặp khó khăn trong việc tách biệt các bản dịch của từng chức năng khác nhau. Trong khi đó, .NET cung cấp sẵn khả năng phân tán các bản dịch của từng trang vào các tệp tài nguyên riêng biệt. Điều này có thể gây phiền phức ban đầu, nhưng về lâu dài lại là một quyết định thông minh.

Tuy nhiên, điểm hạn chế duy nhất là .NET không có khả năng tự động trích xuất văn bản thành tệp tài nguyên giống như Android Studio. Các đoạn văn bản cứng mã hóa cũng không có cảnh báo nào từ Visual Studio, điều này cho thấy sự thiếu chú trọng đến vấn đề quốc tế hóa trong công cụ này. Để tham khảo thêm, bạn có thể xem hướng dẫn về i18n đa ngôn ngữ trong ASP.NET Core in .NET 8.

Tôi đã thử nghiệm phương pháp triển khai AOT (Ahead-of-Time Compilation) của .NET 8. Mặc dù AOT có ưu điểm nhất định, nhưng nếu tính cả thư mục wwwroot và các tệp cấu hình, cách triển khai này vẫn chưa thuận tiện bằng phương pháp triển khai đơn tệp của golang. Golang có thể đóng gói các tệp tài nguyên tĩnh và mẫu của gin vào tệp nhị phân thông qua go embed.FS, trong khi tôi chưa tìm thấy giải pháp tương tự cho .NET. Thậm chí đối với các dự án Rust, tôi cũng chưa thấy cách triển khai đơn giản như vậy.

Do đó, việc sử dụng phương pháp triển khai không AOT cũng là lựa chọn chấp nhận được đối với tôi. Quy trình triển khai hiện tại của dự án .NET 8 MVC bao gồm:

  • Sử dụng lệnh dotnet publish để tạo thư mục tệp triển khai
  • Đồng bộ hóa thư mục publish với thư mục chỉ định trên máy chủ Ubuntu bằng lệnh rsync
  • Khởi động lại dịch vụ dotnet trên máy chủ bằng systemctl

Điều duy nhất tôi lo ngại là các phiên bản thấp của Ubuntu Server có thể không hỗ trợ Runtime của .NET 8. May mắn thay, máy chủ Ubuntu Server thấp nhất mà tôi đang sử dụng là phiên bản 18.04, và nó có Docker. Nếu cần thiết, tôi có thể triển khai bằng Docker.

Sau khi sử dụng .NET CLI để tạo một dự VSBET án .NET 8 MVC mới trong dòng lệnh, tôi có thể dễ dàng tiếp tục phát triển bằng VIM mà không cần đến Visual Studio. Việc này không hề gây trở ngại gì.

Tuy nhiên, tôi vẫn chưa quen thuộc hoàn toàn với .NET CLI, đặc biệt là các lệnh để tạo:

  • Trang Razor
  • Controller MVC
  • Tệp tài nguyên dành cho bản dịch i18n

Dù có thể tạo thủ công các thành phần này, nhưng quá trình này hơi rườm rà và kém thanh lịch. Có lẽ tôi cần tự tùy chỉnh các lệnh để tối ưu hóa quy trình hơn. Sẽ tìm hiểu thêm về vấn đề này sau.