Các lớp tiện ích trong MVC - ASP.NET

Vì vậy, hôm nay tôi đã tự hỏi, bạn sẽ đặt các lớp tiện ích trong một ứng dụng ASP.NET MVC ở đâu? Theo các lớp tiện ích, ý tôi là các lớp có thể tĩnh và chỉ được sử dụng để thực hiện một chức năng. Giống như một lớp để gửi email lấy địa chỉ email, chủ đề và nội dung làm đối số.
Tôi cho rằng có thể tạo một thư mục riêng và không gian tên sẽ đủ tốt, nhưng muốn lấy ý kiến ​​của mọi người

Bạn không. Và ví dụ của riêng bạn là một ví dụ hoàn hảo để chỉ ra tại sao không.

Bạn muốn gửi email, phải không? Vì vậy, bạn tạo ra một nơi nào đó một lớp tĩnh CommunicationUtilitiesvới một tĩnh SendEmail()trong đó. Bạn sử dụng phương thức này từ một số lớp thực hiện một loạt các công cụ, ví dụ như đặt lại mật khẩu của người dùng và gửi cho anh ta một mật khẩu mới qua email. Hoàn hảo.

Bây giờ, điều gì xảy ra nếu bạn muốn kiểm tra đơn vị lớp học của bạn? Bạn không thể, bởi vì mỗi khi bạn muốn kiểm tra phương thức đặt lại mật khẩu, nó sẽ thay đổi cơ sở dữ liệu (không phù hợp với kiểm tra đơn vị) và hơn nữa sẽ gửi email (thậm chí còn tệ hơn).

Bạn có thể đã đọc về Inversion of Control, có lợi ích giúp việc kiểm tra đơn vị dễ dàng hơn. Các bài viết về IoC sẽ giải thích cho bạn rằng thay vì làm một cái gì đó như:

void ResetPassword(UserIdentifier userId)
{
    ...
    new MailSender().SendPasswordReset(userMail, newPassword);
}

bạn làm:

void ResetPassword(IMailSender sender, UserIdentifier userId)
{
    ...
    sender.SendPasswordReset(userMail, newPassword);
}

cho phép sử dụng giả và sơ khai.

Hãy thử áp dụng IoC cho bạn CommunicationUtilities. Phải, bạn không thể. Đó là lý do tại sao nó bị hỏng.

Câu hỏi là một câu hỏi hợp lệ, ngay cả khi ví dụ đưa ra là không. Câu trả lời được đưa ra bởi Maina là hoàn hảo, trong một bối cảnh rất cụ thể, không phù hợp với tôi, bối cảnh thích hợp cho các lớp "tiện ích" đã nói .

Cá nhân, tôi tạo một thư mục Helperstrong đó tôi đặt các hàm đơn giản được gọi từ mọi nơi, như các phần mở rộng, trong trường hợp đó, vâng, chúng là tĩnh.

Bây giờ, nếu có một cách tốt hơn, tôi sẽ rất vui khi học, nhưng cho đến nay:

• Tôi thấy không có gì sai với Tiện ích mở rộng.
• Tôi thấy không có gì sai khi nhóm chúng trong một Thư mục cụ thể.

Bây giờ, một phần mở rộng chỉ là đường cú pháp, nó cũng có thể là một chức năng cổ điển.

Không có câu trả lời nào trước đây đưa ra câu hỏi thực tế. user60812 chỉ cần hỏi nơi người ta sẽ đặt một lớp tiện ích bên trong một dự án MVC. Mọi người đều nghe theo ví dụ số ít và ca ngợi về tất cả mọi thứ trừ câu hỏi trong tầm tay.

@ user60812, tùy thuộc vào mức độ trừu tượng mà bạn muốn, tôi sẽ:

• A) Tạo một thư mục và tạo lớp tiện ích trong thư mục đó
• B) Tạo một dự án để giữ các lớp tiện ích (giả sử mong muốn tái sử dụng lắp ráp).
• C) Ngoại suy các tiện ích của bạn thành một kiến ​​trúc dịch vụ và gọi cho chúng

Đây là một liên kết đến một câu hỏi tương tự với câu trả lời tốt hơn.

IMHO

Đừng tạo các lớp tĩnh cho các tiện ích. Thống kê là xấu trong hầu hết các trường hợp. Đừng gọi họ là quản lý. Bất cứ điều gì bạn đang làm việc, nó nên được đặt trong một không gian tên logic.

Ví dụ:

namespace Application.Notifications.Email
{
   public interface ISendEmailCommand
   {
      void Execute(Email email);
   }
}

Địa chỉ email, chủ đề và cơ thể là một mối quan tâm riêng biệt, do đó tôi sẽ có một cấu trúc lớp cho điều đó, do đó tại sao tôi đã sử dụng Email emailtrong ví dụ trên.