Net dünyası neden statik olarak yazılmış alternatifler yerine sihirli dizeleri kucaklıyor?

Ben de çalışıyorum. Net'te açık kaynaklı projeler yapıyorum. Onunla ilgili en büyük sorunlarımdan biri .Net ile zorunlu değil, etrafındaki topluluk ve çerçevelerle. Her yerde sihirli isimlendirme şemaları ve dizgileri her şeyi yapmanın en iyi yolu olarak görülüyor. Kalın ifade, ama şuna bak:

ASP.Net MVC:

Merhaba dünya rotası:

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

Bunun anlamı, ASP.Net MVC'nin bir şekilde HomeControllerkodunuza bakacağıdır . Her nasılsa bunun yeni bir örneğini oluşturup, işlevi Index görünüşte bir idtür parametreyle çağırın . Ve sonra gibi başka şeyler var:

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

Ve sonra XAML ile de benzer şeyler var. DataContextbir nesne olarak kabul edilir ve istediğiniz tipe çözülmesi için umut etmeli ve dua etmelisiniz. Bağımlılık Özellikleri, sihirli dizeler ve sihirli adlandırma kuralları kullanmalıdır. Ve bunun gibi şeyler:

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

Her ne kadar döküm ve çeşitli büyülü çalışma zamanı desteklerine dayanıyor olsa da.

Her neyse, hepsinin buraya gelmesini söylüyorum: .Net dünyasında neden bu kadar iyi tolere ediliyor? Neredeyse her zaman şeylerin ne olduğunu bilmek için statik olarak yazılmış dilleri kullanmıyor muyuz? Yansıma ve tür / yöntem / özellik / neden isimler (dizeler olarak) jenerikler ile delegeler ve hatta kod oluşturma ile karşılaştırıldığında bu kadar çok tercih edilir?

ASP.Net'in yönlendirme sözdiziminin, aslında bir rotanın nasıl işleneceğini çözmek için neredeyse yalnızca yansımaya dayanmasının neden olmadığına dair eksik olduğumu mi düşünüyorsunuz? Bir yöntemin veya özelliğin adını değiştirdiğimde ve aniden işler kırıldığından nefret ediyorum, ancak o yönteme veya özelliğe herhangi bir atıfta bulunmadığı görülüyor ve tabii ki derleyici hatası yok. Neden sihirli tellerin görünür rahatlığı "buna değer" olarak kabul edildi?

Bazı şeylere genellikle statik olarak yazılmış alternatifler olduğunu da biliyorum, ancak bunlar genellikle arka koltukta geçiyor ve hiçbir zaman öğretici veya başka başlangıç ​​materyali olarak görünmüyor.

Aslında .NET dünyasında bahsettiğiniz bu şeylere karşı bir geri dönüş var. Ancak verdiğiniz ilk örnekte, yönlendirme motoruna varsayılan rotayı eşlemek için bir kural verilmiştir. Rotaların dinamik olması, statik bir konfigürasyon kullanmayı neredeyse imkansız hale getirir.

Ayrıca, her ikisi de jenerikler .NET'e tanıtılmadan önce geliştirilme aşamasında olan ve jenerikleri desteklemeye geri dönerek çok geç bir ürünü (Longhorn / Vista) daha da geciktirmiş olacak olan XAML / WPF'den de bahsediyorsunuz.

Sihirli dizeler yerine lambda ifadeleri kullanma ASP.NET MVC çerçevesi içinde örnekler vardır ve Entity Framework / LINQ, dilin ve çerçevenin statik bir nesne grafiği üzerinde SQL sorguları oluşturmak için yerel destek sağladığı yerlerde daha da ileri götürür sihirli SQL dizeleri, sorgularınızın derleme zamanı doğrulamasını alırsınız).

Diğer statik yapılandırma örnekleri için yapı haritası ve diğer modern bağımlılık enjeksiyon kaplarına ve çalışma zamanında nesne grafiğini incelemesi gereken ancak geliştiricinin lambda ifadeleri kullanarak statik olarak ipuçları sağlamasına izin veren diğer çerçevelere bakın.

Yani kısa cevap tarihsel olarak, .NET 3.5 sürümüne kadar bir nesne grafiğinin statik geçişini desteklemediğidir. Artık sahip olduğumuz için, birçok geliştirici onu sihirli dizgilere tercih ediyor ve birçoğu operatörün bir sembolü olan operatör gibi daha derin bir destek için daha da zorlanıyor.