Razor Pages adalah fitur baru yang diperkenalkan di Core.Net 2.0. Halaman Razor adalah halaman yang terdiri dari tata letak standar (Tampilan) dan kelas backend. Dalam arti, itu menyerupai Formulir Web hanya tanpa dukungan negara. Keuntungan dari solusi semacam itu sangat jelas - kita menyingkirkan lapisan yang tidak perlu - model halaman (model data dalam bentuk, misalnya, Entitas dengan sendirinya). Backend halaman merupakan pengontrol dan model - OOP classic - mengenkapsulasi data dan metode untuk bekerja dengannya dalam satu objek. Pada akhirnya, model halaman hanya kelas, tidak ada alasan mengapa controller tidak dapat kelas ini.
Dengan kata lain, Razor Pages adalah solusi web yang lebih waras daripada MVC, sekarang kita berurusan dengan konsep "halaman" tradisional dan logis dan tidak dengan pengontrol dan model yang tersebar di seluruh proyek. Tetapi karena .NET akan berkembang ke arah Core.Net, tidak mungkin Razor Page akan muncul dalam kerangka kerja standar, meskipun pada kenyataan di tahun-tahun mendatang sebagian besar proyek akan tetap pada standar .NET. Namun demikian, dimungkinkan untuk menggambarkan fungsionalitas Halaman Razor pada kerangka kerja standar.
Solusinya sebenarnya terlihat cukup sepele - Anda perlu menambahkan desain berikut ke controller:
protected override void OnActionExecuting(ActionExecutingContext Context) { UpdateModel(this); }
Metode OnActionExecuting adalah peristiwa siklus hidup yang dipanggil sebelum metode pengontrol dijalankan (artinya penangan permintaan - Aksi).
UpdateModel secara langsung mengikat parameter permintaan ke properti model - dalam hal ini, properti dari kelas pengontrol.
Kenyamanan tambahan - sekarang tidak perlu sama sekali untuk secara eksplisit menerima parameter dari kedua jenis Model atau lainnya. Meskipun tidak ada yang mencegah hal ini, jika parameternya adalah id sederhana yang akan digunakan murni sebagai variabel lokal, parameter yang mengikat sebagai properti dari pengontrol diperlukan, misalnya, jika Anda ingin memastikan kegigihan halaman, yang akan dibahas nanti.
Contoh sederhana:
Kami memiliki formulir login biasa dengan dua bidang.
Tidak ada gunanya menandai, saya hanya akan memberikan kode controller
public class AccountController : Controller { public string username{ get; set; } public string userpass{ get; set; } [HttpPost] public ActionResult OnLogin( ) {
Seperti yang Anda lihat, pada saat acara dipicu, data input sudah terikat dan siap digunakan.
Tentu saja, kita harus ingat bahwa sekarang kita harus kembali sebagai ActionResult controller juga, dan dalam template mendaftarkan nama kelas controller - seperti @Model AccountController.
Sebagai konsekuensi dari solusi ini, tugas mempertahankan keadaan halaman di antara permintaan juga disederhanakan. Katakanlah Anda memiliki halaman dengan tabel tertentu, filter yang disortir berdasarkan kolom dan pagination.
Anda mengklik filter, model kembali ke tampilan dan semuanya baik-baik saja, tetapi ketika Anda mengklik penyortiran, filter akan secara alami diatur ulang. Paginator akan mengatur ulang penyortiran dan filter. Di WebForms, keadaan halaman disimpan secara otomatis, di MVC Anda harus menerapkan berbagai keputusan rumit, misalnya, merekatkan semua parameter dan mengarahkannya untuk setiap permintaan, yaitu, Anda perlu menggantung semua parameter yang datang sebelum ini dari filter pada tautan sortir.
Kesulitan seperti itu adalah salah satu alasan SPA dan kegilaan javascript lainnya dengan menyeret logika dan data ke browser dengan rem browser yang dihasilkan (terutama perangkat seluler), halaman melompat dan menyentak untuk setiap gerakan mouse dan meningkatkan kompleksitas dan biaya pekerjaan - karena backend sama saja menulis dalam satu atau lain bentuk, kemas membongkar data yang dikirim melalui ajax, ditambah panggilan neraka, komplikasi debugging dan sebagainya, dan semua ini tanpa manfaat praktis bagi pengunjung situs yang tidak peduli bagaimana Halaman Isana.
Solusi paling logis adalah menyimpan status halaman dalam sesi. Karena kita memiliki semua parameter yang diperlukan dalam bentuk properti controller, semua yang diperlukan adalah mendefinisikan kembali metode OnActionExecuted, yang dipanggil setelah memproses permintaan, dan kemas properti yang diperlukan ke dalam sesi (kunci sesi jelas harus menunjuk ke nama controller).
protected override void OnActionExecuted (ActionExecutedContext Context) {
Parameter dipulihkan dari sesi di konstruktor controller atau sebelum memanggil UpdateModel (ini). Ketika permintaan tiba, misalnya, penyortiran, parameter baru akan berubah dan sisanya akan tetap tak tersentuh dan tampilan akan ditampilkan dalam bentuk yang sama seperti yang dikirim.
Solusi semacam itu memiliki satu lagi kemudahan - misalnya, pengguna mengurutkan tabel, dan memutuskan untuk mengedit beberapa elemen dengan membuka halaman lain untuk ini. Secara alami, ia ingin kembali ke keadaan daftar yang ia tinggalkan, dan karena keadaan halaman ada di sesi kami, halaman akan dipulihkan secara otomatis. Tidak perlu, seperti yang sering dilakukan, untuk mentransfer seluruh "pangsit" parameter ke halaman edit dan sebaliknya. Jika tidak perlu menyimpan status antar halaman, maka status halaman tidak dapat disimpan dalam satu sesi, tetapi dalam TempData.
Saya berharap "peretasan kehidupan" ini, meskipun terlihat sepele, akan berguna bagi pemula sampai mereka memata-matai internet untuk solusi yang lebih tidak nyaman dan rumit dan memutuskan bahwa tidak ada yang lain.