Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. ASP.NET

Menghasilkan URL tradisional dengan ASP.NET MVC3

by
Read Time:12 minsLanguages:

Indonesian (Bahasa Indonesia) translation by Keti Pritania (you can also view the original English article)

Ada kebenaran tertentu di dunia: kita dilahirkan, kita mati, dan URL harus diakhiri dengan garis miring jika itu tidak mengarah ke file. Kerangka kerja ASP.NET MVC menghasilkan tradisi dan konvensi, dan metode bawaan yang menghasilkan URL melakukannya dengan menghilangkan garis miring. Ini mungkin tampak seperti non-isu (dan banyak orang tidak satu), tapi banyak pengembang, penulis ini termasuk, disadap oleh mereka.


Pertama, beberapa latar belakang

URL adalah singkatan dari Uniform Resource Locator; itu memberi tahu klien yang sadar web di mana menemukan sumber daya tertentu di Internet. URL https://www.example.com/directory/file.html poin ke file fisik (sumber daya) disebut file.html yang berada dalam sebuah direktori yang disebut direktori web server di example.com domain. Ketika web server example.com menerima permintaan untuk URL itu, ia tahu persis di mana untuk mencari sumber daya. Jika menemukan file, menyajikan isinya; Jika tidak, merespon dengan kesalahan.

Server web tradisional melakukan hal yang sama untuk permintaan direktori.

Pertimbangkan URL http://www.example.com/directory/. URL ini berakhir dengan garis miring, yang menunjukkan direktori. Ketika web server menerima permintaan ini, tampaknya untuk direktori direktori, dan jika ia menemukan itu, mendapatkan dokumen default dan kembali ke klien. Sebaliknya, ia menanggapi dengan kesalahan.

Dua contoh ini menunjukkan proses yang sederhana, tetapi itu bisa mendapatkan lebih kompleks dengan permintaan ambigu. Misalnya, URL http://www.example.com/ambiguous poin untuk sumber daya yang disebut ambigu, tetapi tidak jelas apakah sumber daya. Ini bisa menjadi sebuah file, tetapi tidak ada ekstensi; ini bisa menjadi sebuah direktori, tapi ada tidak miring. Bila menerima permintaan sumber daya ini, tradisional web server berjalan melalui proses berikut:

  • Server mencari file bernama ambigu. Jika menemukan satu, itu kembali itu. Jika tidak...
  • Mengirimkan respon balik ke klien, mengarahkan ke http://www.example.com/ambiguous/
  • Klien meminta URL baru
  • Server mencari direktori ambigu dan mengembalikan respon yang tepat

Tanpa secara eksplisit menentukan sumber daya, Penanya menciptakan overhead dalam kedua pengolahan penggunaan waktu dan bandwidth.

Tanpa secara eksplisit menentukan sumber daya, Penanya menciptakan overhead dalam kedua pengolahan penggunaan waktu dan bandwidth. Untuk alasan ini, aturan berlaku telah menempatkan akhiran garis miring pada semua URL yang mengarah ke sebuah direktori. Melakukan sehingga benar-benar menghilangkan penggunaan pengolahan membuang-buang waktu dan bandwidth. Hal ini telah menjadi kebiasaan bagi banyak (mungkin sebagian?) web veteran untuk selalu menyertakan garis miring pada akhir URL yang tidak menunjuk ke file.

Jadi mana Apakah ASP.NET MVC cocok ke dalam ini? Yah, ASP.NET, seperti yang mungkin Anda ketahui, biasanya berjalan pada server web Microsoft, disebut IIS. IIS, secara default, berperilaku seperti server web lain, tetapi kekuatan sebenarnya terletak pada kemampuannya untuk meneruskan penanganan permintaan ke modul ISAPI atau, bahkan lebih baik, kode .NET. Dalam kasus aplikasi ASP.NET MVC, IIS melewati setiap permintaan untuk app MVC untuk pengolahan. Di sana, app menentukan jika permintaan harus dialihkan ke metode pada kontroler, atau jika itu harus lulus kontrol kembali ke IIS untuk menemukan fisik file atau direktori pada sistem file. Begitu proses penanganan permintaan untuk http://www.example.com/ambiguous dengan IIS app MVC terlihat seperti ini:

Tunggu, tunggu, tunggu! Jika aplikasi MVC mengabaikan akhiran garis miring, apa masalahnya?

Ketika aplikasi merutekan permintaan ke controller, metode pada controller itu dijalankan, memproses data apa pun yang dibutuhkan, dan mengembalikan hasilnya ke klien. Itu tidak mengarahkan klien ke URL lain (kecuali jika metode yang seharusnya untuk melakukannya). MVC aplikasi tidak peduli jika URL berakhir dengan garis miring atau tidak - sebenarnya, MVC apps mengabaikan akhiran garis miring. Selama URL cocok dengan pola dalam tabel routing, aplikasi MVC akan menangani permintaan dan mengembalikan respons yang diminta tanpa menyebabkan overhead tambahan.

Tunggu, tunggu, tunggu! Jika aplikasi MVC mengabaikan akhiran garis miring, apa masalahnya? Secara teknis, tidak ada satu. URL ambigu sebenarnya menunjuk ke sumber daya pada server: metode pada objek controller dalam aplikasi. Tapi seperti yang dinyatakan sebelumnya, pengembang web telah meletakkan garis miring pada akhir tahun URL mereka sebelum Microsoft merilis kerangka kerja MVC. It's kebiasaan dan konvensi untuk melakukannya.

Microsoft sikap pada "masalah" hanyalah agar konsisten dengan URL yang digunakan dalam aplikasi kita, dan itulah sikap teknis yang benar. Tetapi dalam mode Microsoft khas, kerangka kerja MVC metode pembantu hanya menghasilkan URL tanpa trailing garis miring-yang berarti pengembang harus menulis kode mereka sendiri untuk mencapai "benar" URL. Solusi yang disajikan dalam artikel ini dua kali lipat:

  • Membuat metode ekstensi yang menghasilkan URL
  • Menulis disesuaikan versi metode RouteLink().

Karena solusi ini menggunakan variasi dari RouteLink(), sangat penting bahwa rute Anda diberi. Jika Anda sedang tidak menyebut rute Anda, Anda harus! Akhirnya, beberapa kode!


Menghasilkan URL

Kerangka kerja MVC menyediakan kelas yang disebut UrlHelper. Seperti namanya, tujuannya adalah untuk membantu dengan menghasilkan URL untuk aplikasi kita. Hotel ini memiliki sebuah metode statis yang disebut GenerateUrl() yang akan melakukan sebagian besar kerja keras bagi kita. Yang harus kita lakukan adalah memberikan nama rute dan nilai rute. Kami akan membuat metode extention untuk objek HtmlHelper yang disebut RouteUrl(), dan itu akan memiliki dua kelebihan.

Menulis metode overload cukup mudah. Biasanya ada satu yang berlebihan yang melakukan semua pekerjaan (satu berlebihan untuk memerintah mereka semua), dan overload lain hanya melewati argumen mereka untuk itu. Jadi Anda akan mulai dengan menulis kelebihan utama, dan kode berikut:

Metode ekstensi menerima tiga argumen. Yang pertama adalah objek HtmlHelper yang metode ini beroperasi pada. Catatan saat memanggil metode ini, Anda tidak perlu pass objek HtmlHelper; yang dilakukan secara otomatis untuk Anda. Argumen kedua adalah string yang berisi nama rute. Metode GenerateUrl() yang akan menggunakan rute yang nama untuk kembali URL yang diformat benar menurut pola rute yang didefinisikan dalam tabel routing. Argumen terakhir adalah sebuah objek RouteValueDictionary, yang berisi serangkaian kunci/nilai pasangan dengan semua informasi yang diperlukan untuk menghasilkan URL untuk rute. Ini termasuk controller dan aksi nama, serta parameter UrlHelper mungkin perlu menghasilkan URL untuk rute tertentu.

Pernyataan pertama metode panggilan UrlHelper.GenerateUrl() untuk menghasilkan URL. Ada dua overload GenerateUrl() metode, dan kode di atas panggilan satu dengan sedikitnya jumlah parameter. Nama rute dilewati, tetapi Anda mengabaikan parameter yang menentukan nama tindakan dan pengontrol. Nilai-nilai ini sebenarnya disimpan dalam objek routeValues, yang diteruskan ke GenerateUrl() sebagai argumen keempat. Objek HtmlHelper yang memberi Anda dua potongan informasi yang Anda butuhkan, dan argumen akhir yang dilewatkan menceritakan GenerateUrl() untuk memasukkan nilai-nilai MVC implisit "aksi" dan "controller".

Setelah URL yang dihasilkan, metode RouteUrl() panggilan String.Format() untuk membuat string baru, pada dasarnya menggabungkan URL dan miring. Catatan bahwa String.Format() tidak diperlukan, dan Anda hanya dapat menulis return url + "/";. Bagaimana Anda membuat string adalah terserah Anda.

Dengan kelebihan utama pekerja yang ditulis, sekarang menambahkan satu malas. Berikut adalah kode:

Kode ini adalah lurus ke depan. Ini panggilan berlebihan RouteUrl() utama lewat data yang sesuai. Karena metode ekstensi metode statis, mereka bisa disebut seperti apapun lainnya statis metode-yang adalah kasus dalam kode ini. Perhatikan bahwa Anda bisa dengan mudah ditulis kode ini dengan menelepon RouteUrl() utama sebagai metode contoh (ekstensi), seperti ini:

Tidak masalah. Bagaimanapun, pekerjaan akan dilakukan; itu datang ke preferensi pribadi Anda.

Memanggil metode ini dari pandangan Anda cukup sederhana. Pertama, pastikan namespace yang mengandung kelas HtmlHelperExtensions diimpor, dan cukup gunakan sintaks berikut:

Tentu saja, nilai untuk controller dan action, serta parameternya, akan berbeda untuk aplikasi MVC spesifik Anda. Tetapi ini memberi Anda gambaran tentang bagaimana menggunakan metode ini. Sekarang bahwa Anda dapat menghasilkan URL yang cantik dengan trailing garis miring, saatnya untuk menulis lebih extension metode untuk menghasilkan link Anda.


Menghasilkan Tautan

Salah satu metode HtmlHelper paling berguna adalah metode RouteLink(). Yang harus Anda lakukan adalah memberikan rute nama dan nilai-nilai untuk mendapatkan string yang berisi elemen jangkar dengan URL relatif cukup untuk tindakan tertentu. Tentu saja, RouteLink() mengembalikan elemen jangkar yang berisi URL tanpa garis miring; jadi, Anda perlu menulis metode Anda sendiri yang menggunakan RouteUrl().

Terdapat sebelas overload untuk RouteLink(), jadi jika Anda ingin menulis versi Anda sendiri semua sebelas, merasa bebas. Artikel ini akan hanya berjalan Anda melalui penciptaan beberapa-mungkin overload paling populer. RouteLink() metode ini benar-benar metode ekstensi, dan karena metode ekstensi tidak dapat diganti atau tersembunyi, Anda harus datang dengan nama metode Anda sendiri. Artikel ini akan super kreatif dan menggunakan MyRouteLink().

Kelebihan utama akan menerima lima argumen: instance HtmlHelper, teks tautan, nama rute, RouteValueDictionary yang berisi informasi rute, dan kamus atribut HTML untuk diterapkan ke elemen jangkar. Seperti RouteUrl(), MyRouteLink() adalah metode statis kelas statis HtmlHelperExtensions. Berikut adalah kode (untuk menghemat ruang, Deklarasi kelas dihilangkan):

Kode ini mungkin terlihat akrab bagi Anda jika Anda telah pernah mempelajari kode sumber ASP.NET MVC. Kelas HtmlHelper memiliki metode pribadi yang disebut GenerateRouteLink(), yang adalah inspirasi untuk MyRouteLink(). Metode Anda mengembalikan sebuah objek MvcHtmlString, yang merupakan string HTML-dikodekan (Anda tidak perlu melakukan encoding sendiri). Pernyataan pertama dari metode ini menggunakan metode RouteUrl() Anda untuk mendapatkan URL khusus. Selanjutnya, Anda menggunakan sebuah objek TagBuilder untuk membangun elemen jangkar, mempopulasikan InnerHtml properti teks link. Maka atribut HTML, yang disediakan oleh kamus dan href atribut, ditambahkan ke elemen. Akhirnya, HTML output dibuat sebagai objek MvcHtmlString dan kembali ke pemanggil.

Kue itu sekarang sebagai overload sisa akan, dalam satu cara atau lain, panggilan versi MyRouteLink(). Kelebihan berikutnya memiliki tanda tangan yang sama; rute nilai-nilai dan atribut hanya akan objek. Berikut adalah kode:

Kode ini adalah diri-explanitory. Anda memanggil MyRouteLink() yang utama berlebihan lewat data yang sesuai. Catatan Anda menggunakan sebuah objek RouteValueDictionary untuk atribut HTML; ini adalah sebuah wadah yang cocok untuk atribut HTML.

Berikutnya, dan terakhir, dua overload lebih dari sama, kecuali mereka tidak menerima argumen untuk atribut HTML. Ini kode mereka:

Kelebihan pertama dalam kode di atas menghilangkan kumpulan atribut HTML dan menentukan objek RouteValueDictionary untuk nilai rute. Ini panggilan berlebihan dengan tanda tangan dari MyRouteLink (HtmlHelper, string, string, RouteValueDictionary, IDictionary<string, object="">), dan melewati sebuah objek RouteValueDictionary yang kosong untuk atribut HTML.</string,> Kelebihan kedua memiliki tanda tangan yang sedikit berbeda, yang menerima objek untuk nilai-nilai rute. Ini panggilan berlebihan pertama dalam kode ini daftar untuk menghasilkan link.

Untuk menggunakan metode penolong ini, pastikan Anda mengimpor namespace yang mengandung kelas HtmlHelperExtensions dalam pandangan Anda. Kemudian, Anda dapat menulis sesuatu seperti ini:

Kode ini menggunakan pisau cukur sintaks, tetapi Anda dapat pada dasarnya melakukan hal yang sama jika menggunakan mesin Lihat ASPX, seperti ini:

Kode tersebut menggunakan baru < %: %> nugget untuk HTML pengkodean output (diperkenalkan di .NET 4). Keindahan MvcHtmlString yang dikembalikan oleh MyRouteLink() adalah bahwa itu sudah dikodekan HTML, dan itu akan tidak kembali dikodekan dengan menggunakan nugget baru. Sehingga Anda dapat menggunakan < %: %> atau < % = %> tanpa khawatir tentang pengkodean atau re-encoding.


Dalam Penutupan

Seperti disebutkan sebelumnya, tidak ada yang secara teknis salah dengan URL genereated oleh kerangka kerja MVC. Mereka tidak menyebabkan overhead, seperti mereka menunjukkan sumber aktual di server. Tetapi jika Anda telah disadap oleh mereka, sekarang Anda dapat menghasilkan URL yang benar secara tradisional dengan hanya sedikit kerja dimuka. Microsoft benar, namun: konsisten. Terlepas dari apa gaya URL yang Anda pilih, pastikan Anda secara konsisten menggunakan yang sama.

Biarkan aku tahu jika Anda memiliki pertanyaan dalam komentar dan terima kasih banyak untuk membaca!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.