Mengapa dunia .Net tampaknya merangkul string sihir alih-alih alternatif yang diketik secara statis?


47

Jadi, saya bekerja di .Net. Saya membuat proyek open source di .Net. Salah satu masalah terbesar saya dengan itu tidak wajib dengan. Net, tetapi dengan komunitas dan kerangka kerja di sekitarnya. Tampaknya di mana-mana skema dan string penamaan magis diperlakukan sebagai cara terbaik untuk melakukan semuanya. Pernyataan berani, tetapi lihatlah:

ASP.Net MVC:

Halo rute dunia:

        routes.MapRoute(
            "Default",                                              // Route name
            "{controller}/{action}/{id}",                           // URL with parameters
            new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
        );

Apa artinya ini adalah bahwa ASP.Net MVC entah bagaimana akan mencari HomeControllerdi kode Anda. Entah bagaimana, buat instance baru darinya, dan kemudian panggil fungsi tersebut Index dengan idparameter. Dan kemudian ada hal-hal lain seperti:

RenderView("Categories", categories);
...or..
ViewData["Foobar"]="meh";

Dan kemudian ada hal-hal serupa dengan XAML juga. DataContextdiperlakukan sebagai objek dan Anda harus berharap dan berdoa agar itu sesuai dengan jenis yang Anda inginkan. DependencyProperties harus menggunakan string ajaib dan konvensi penamaan sulap. Dan hal-hal seperti ini:

  MyData myDataObject = new MyData(DateTime.Now);      
  Binding myBinding = new Binding("MyDataProperty");
  myBinding.Source = myDataObject;

Meskipun lebih mengandalkan casting dan berbagai dukungan runtime ajaib.

Bagaimanapun, saya mengatakan semua itu untuk berakhir di sini: Mengapa ini bisa ditoleransi dengan baik di dunia .Net? Bukankah kita menggunakan bahasa yang diketik secara statis untuk hampir selalu tahu apa jenisnya? Mengapa refleksi dan tipe / metode / properti / nama apa pun (sebagai string) lebih disukai dibandingkan dengan generik dan delegasi atau bahkan pembuatan kode?

Apakah ada alasan bawaan yang saya lewatkan untuk mengapa sintaksis routing ASP.Net bergantung hampir secara eksklusif pada refleksi untuk benar-benar menyelesaikan cara menangani rute? Saya benci ketika saya mengubah nama metode atau properti dan tiba-tiba hal-hal rusak, tetapi tampaknya tidak ada referensi untuk metode atau properti itu dan tentu saja tidak ada kesalahan kompiler. Mengapa kenyamanan nyata dari string sihir dianggap "layak"?

Saya tahu ada juga alternatif yang diketik secara statis untuk beberapa hal, tetapi mereka biasanya mengambil kursi belakang dan sepertinya tidak pernah ada di tutorial atau materi pemula lainnya.


14
Dynamism tanpa tujuan telah menjadi hal yang populer sejak CPU kami cukup cepat untuk menjalankannya.
DeadMG

7
Bagaimana? Saya belum melihat contoh seperti itu dengan LINQ.
DeadMG

6
Dugaan saya yang sederhana adalah bahwa alternatif yang diketik dengan benar secara statis terlalu merepotkan. Itu adalah tema yang banyak muncul dengan kebanyakan sistem tipe: "Kami ingin melakukan ini di sistem tipe, tapi itu tidak cukup ekspresif." (Atau kebalikannya: "Kami berhasil mengungkapkan ini dalam sistem tipe, tapi itu membuat semuanya tiga kali lebih kompleks.") @ GlenH7 Saya tidak terlalu akrab dengan semua LINQ, tetapi bit yang saya gunakan tidak menunjukkan apa pun dekat apa yang dijelaskan posting ini. Mau memberi contoh?

2
@ Earlz Yang lebih penting, objek anonim diketik secara statis. Tidak ada string ajaib, kompiler tahu nama dan tipe dari semua yang terlibat. Simpan untuk setiap penggunaan lainnya var.

1
@ Earlz itu menarik, meskipun orang bisa berpendapat bahwa sintaks lambda adalah mengasapi tambahan di sini. Dugaan saya adalah mereka menggunakan pendekatan sulap / konvensi karena sangat sederhana, "cukup baik" bagi banyak orang, dan mereka selalu dapat mengadaptasi alat untuk memberikan panduan / keamanan. Ini adalah trade off antara keselamatan dan kenyamanan, IMHO. Penggunaan ViewBag yang dinamis juga mengisyaratkan mentalitas ini (bukan berarti saya sepenuhnya setuju dengan itu).
Daniel B

Jawaban:


31

Sebenarnya ada dorongan kembali di dunia .NET terhadap hal-hal yang Anda sebutkan ini. Pada contoh pertama yang Anda berikan, mesin perutean diberikan konvensi untuk memetakan rute default. Fakta bahwa rutenya dinamis membuatnya hampir tidak mungkin untuk menggunakan konfigurasi statis.

Anda juga menyebutkan XAML / WPF, keduanya sedang dalam pengembangan jauh sebelum obat generik diperkenalkan. NET dan kembali ke dukungan obat generik akan menunda produk yang sudah sangat terlambat (Longhorn / Vista) lebih jauh.

Ada contoh dalam kerangka ASP.NET MVC menggunakan ekspresi lambda sebagai pengganti string ajaib dan Kerangka Entitas / LINQ membawanya lebih jauh di mana bahasa dan kerangka kerja menyediakan dukungan asli untuk menyusun pertanyaan SQL di atas grafik objek statis (alih-alih membangun string SQL ajaib, Anda mendapatkan waktu kompilasi validasi dari pertanyaan Anda).

Untuk contoh lain dari konfigurasi statis, lihat structuremap dan wadah injeksi ketergantungan modern lainnya, dan kerangka kerja lain yang perlu memeriksa grafik objek saat runtime tetapi memungkinkan pengembang untuk secara statis memberikan petunjuk menggunakan ekspresi lambda.

Jadi jawaban singkatnya adalah bahwa secara historis, .NET tidak mendukung traversal statis suatu objek grafik hingga rilis 3.5. Sekarang kita memilikinya, banyak pengembang lebih suka daripada string ajaib dan banyak yang mendorong untuk dukungan yang lebih dalam seperti operator simbolOf yang bekerja mirip dengan operator typeOf.


3
XAML adalah verbose seperti itu ... menambahkan dukungan untuk obat generik akan membuatnya bahkan lebih (ya saya tahu seluruh XAML tidak dibuat untuk manusia Argumen). Selain itu, saya melihat XAML lebih mirip dengan HTML daripada bahasa pemrograman yang sebenarnya. Seharusnya tidak peduli tentang jenis objek yang ditampilkan, hanya bagaimana menampilkannya.
Michael Brown

2
Generik tiba di 2.0, tetapi kami tidak mendapatkan Ekspresi hingga 3,5 (dengan LINQ). Ekspresi adalah kekuatan LINQ dan komunitas telah mengambil kekuatan itu dan menjalankannya. Teknik ini dikenal sebagai refleksi statis
Michael Brown

1
Poin bagus tentang refleksi statis. Saya lupa tentang itu diperkenalkan di 3,5
Earlz

2
Ini adalah jawaban yang bagus dan saya pasti setuju dengan pushback. Semua hal ini saya hindari seperti wabah karena jika ada kesalahan ketik atau bug mereka hanya tertangkap saat runtime, artinya mereka dapat dengan mudah dilewatkan. Mereka juga membuat refactoring sangat berbeda. Hindari menghindari menghindari!
Rocklan

2
Setuju pada pushback. T4MVC adalah proyek yang melompat ke pikiran yang bercita-cita untuk menghapus banyak string dan menggantinya dengan kode yang sangat diketik.
Carson63000
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.