Pada awal projek, satu action dalam controller boleh kelihatan cukup ringkas: terima permintaan, baca rekod, simpan dan pulangkan respons. Enam bulan kemudian ia turut menghantar e-mel, mengira diskaun, menulis log audit dan memanggil API lain. Controller yang asalnya mudah dibaca menjadi tempat semua keputusan berkumpul.
Cari sempadan tanggungjawab
Sebelum memindahkan kod, tulis aliran yang action itu lakukan. Pengesahan input dan pemilihan respons HTTP memang dekat dengan controller. Peraturan perniagaan seperti kelayakan diskaun boleh diletakkan dalam service yang mempunyai nama jelas. Akses data pula perlu dikendalikan melalui komponen yang boleh diuji tanpa memanggil endpoint sebenar.
Jangan pecahkan satu action menjadi sepuluh class hanya untuk mengurangkan bilangan baris. Mulakan dengan bahagian yang paling kerap berubah atau paling sukar diuji. Contohnya, asingkan pengiraan harga dahulu, tambah ujian untuk beberapa kes tepi, kemudian ubah controller supaya memanggil fungsi tersebut. Satu perubahan kecil yang boleh disemak lebih selamat daripada refactor besar tanpa sempadan.
Contoh sempadan yang boleh diuji ialah pengiraan diskaun. Jika ia kini bercampur dengan return Ok(...) dan panggilan pangkalan data, pindahkan pengiraan ke komponen kecil yang menerima input jelas dan memulangkan hasil. Uji beberapa keadaan tanpa perlu memulakan server. Itu bukti pemisahan benar-benar membantu, bukan sekadar menambah fail.
Perhatikan juga operasi luaran. Jika e-mel gagal selepas transaksi disimpan, apakah respons yang patut dilihat pengguna? Soalan ini sering tersembunyi apabila semuanya berlaku dalam satu method. Dokumentasi rasmi ASP.NET Core MVC boleh menjadi rujukan asas, tetapi reka bentuk akhir masih bergantung pada aliran sebenar aplikasi anda.