Kelas Utilitas di MVC - ASP.NET


15

Jadi saya bertanya-tanya hari ini, di mana Anda akan menempatkan kelas utilitas dalam aplikasi ASP.NET MVC? Dengan kelas utilitas yang saya maksud adalah kelas yang bisa statis dan hanya digunakan untuk melakukan suatu fungsi. Seperti kelas untuk mengirim email yang menggunakan alamat, subjek, dan isi email sebagai argumen.
Saya akan berasumsi mungkin membuat folder terpisah dan namespace akan cukup baik, tetapi ingin mendapatkan pendapat semua orang


3
Mengapa akan membuat kelas utilitas di semua jenis proyek? Mengapa MVC dipilih dalam pertanyaan Anda?
Oded

1
Yah saya bertanya-tanya tentang MVC karena dengan cara memaksa struktur. Dan sejauh utilitas, saya mendapat kesan semua orang menggunakannya :) Jika saya memiliki kode pengirim email, dan saya membaginya menjadi kelas terpisah untuk bekerja dengan berbagai bagian sistem, bukankah itu kelas utilitas atau saya Aku bingung? Saya pikir kelas utilitas pernah digunakan kembali dalam program apa pun yang tidak terikat ke dalam kode
user60812

Saya pribadi akan mempertimbangkan pengiriman email layanan, disarikan oleh katakanlah antarmuka IUserNotificationSender atau lebih .. dengan penanganan kesalahan yang tepat, konfigurasi smtp dll yang tidak benar-benar cocok dalam fungsi utilitas ...
Maks

@ Max jadi apa yang akan dianggap sebagai fungsi utilitas? Saya mencoba untuk memahami, karena menurut saya saya sangat bingung
user60812

Nah, fungsi utilitas yang tepat dalam pikiran saya adalah fungsi yang sangat kecil dengan ruang lingkup yang sangat jelas dan tidak ada ketergantungan eksternal ... Seperti fungsi untuk menghapus spasi, atau memangkas string, atau mendapatkan elemen ke-9 koleksi ...
Maks

Jawaban:


11

Kamu tidak. Dan teladan Anda sendiri adalah contoh yang sempurna untuk menunjukkan mengapa tidak.

Anda ingin mengirim email, bukan? Jadi, Anda membuat suatu tempat kelas statis CommunicationUtilitiesdengan statis SendEmail()di dalamnya. Anda menggunakan metode ini dari beberapa kelas yang melakukan banyak hal, misalnya mengatur ulang kata sandi pengguna dan mengirimkannya yang baru melalui email. Sempurna.

Sekarang, apa yang terjadi jika Anda ingin menguji unit Anda di kelas? Anda tidak bisa, karena setiap kali Anda ingin menguji metode yang mengatur ulang kata sandi, itu mengubah database (yang tidak cocok untuk uji unit), dan bahkan mengirim email (yang bahkan lebih buruk).

Anda mungkin telah membaca tentang Inversion of Control, yang memiliki manfaat membuat pengujian unit lebih mudah. Artikel tentang IoC akan menjelaskan kepada Anda bahwa alih-alih melakukan sesuatu seperti:

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

Anda melakukannya:

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

yang memungkinkan untuk menggunakan tiruan dan bertopik.

Cobalah untuk menerapkan IOC ke Anda CommunicationUtilities. Benar, kamu tidak bisa. Itu sebabnya rusak.


Hai MainMa, jadi jika saya mengerti benar itu masih tepat untuk membuat kelas latar belakang say dengan semua perpipaan, dan kemudian abstrak dengan antarmuka, dan meneruskan antarmuka ke fungsi alih-alih panggilan langsung dari kelas seperti dalam cuplikan pertama Anda.
user60812

1
@ user60812: singkatnya, baca tentang IoC. Akan sulit untuk menjelaskan keseluruhan subjek dalam komentar sederhana.
Arseni Mourzenko

1
Bagaimana dengan fungsi utilitas yang benar-benar generik, seperti truncator string?
jbyrd

2
@MainMa - maaf, saya tidak mengikuti. Itulah yang saya inginkan, ya. Tapi Truncate () tidak dibangun ke dalam c #, jadi saya bertanya-tanya apakah masuk akal untuk tetap menggunakan fungsi utilitas generik semacam itu di semacam kelas utilitas.
jbyrd

2
Jawaban ini mendefinisikan masalah dengan mencatat bahwa dalam kasus khusus ini tidak perlu kelas util. Tetapi secara umum selalu ada beberapa metode gaya "pembantu" yang tidak cocok di mana pun.
usr

9

Pertanyaannya adalah yang valid, bahkan jika contoh yang diberikan tidak. Jawaban yang diberikan oleh Maina adalah sempurna, dalam konteks yang sangat spesifik, yang tidak bagi saya, konteks yang tepat untuk kelas "utilitas" tersebut .

Secara pribadi, saya membuat folder Helpersdi mana saya meletakkan fungsi sederhana untuk dipanggil dari mana saja, seperti ekstensi, dalam hal ini, ya, mereka statis.

Sekarang, jika ada cara yang lebih baik, saya akan senang belajar, tetapi sejauh ini:

  • Saya tidak melihat ada yang salah dengan Ekstensi.
  • Saya melihat tidak ada yang salah dengan mengelompokkannya dalam Folder tertentu.

Sekarang, ekstensi hanyalah gula sintaksis, bisa juga merupakan fungsi klasik.


6

Tidak ada jawaban yang diberikan sebelumnya menjawab pertanyaan aktual. user60812 hanya bertanya di mana orang akan menempatkan kelas utilitas di dalam proyek MVC. Semua orang menggunakan contoh tunggal dan mengoceh tentang segala hal kecuali pertanyaan yang ada.

@ user60812, tergantung pada tingkat abstraksi yang Anda inginkan, saya akan:

  • A) Buat folder dan buat kelas utilitas di dalam folder itu
  • B) Buat proyek untuk mengadakan kelas utilitas (dengan asumsi keinginan untuk menggunakan kembali perakitan).
  • C) Ekstrapolasi utilitas Anda ke dalam arsitektur layanan dan memanggil mereka

Berikut ini tautan ke pertanyaan serupa dengan jawaban yang lebih baik.

Menurut opini saya


1

Jangan membuat kelas statis untuk utilitas. Statika buruk dalam banyak kasus. Jangan panggil mereka manajer juga. Apa pun yang sedang Anda kerjakan, itu harus ditempatkan di namespace logis.

Sebagai contoh:

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

Alamat email, subjek dan tubuh adalah masalah yang terpisah, oleh karena itu saya akan memiliki struktur kelas untuk itu, maka dari itu mengapa saya menggunakan Email emailcontoh di atas.


Tolong jelaskan mengapa kelas statis buruk untuk menyimpan metode utilitas? Saya benar-benar ingin tahu alasan Anda.
Spencer Sullivan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.