Perché il mondo .Net sembra abbracciare stringhe magiche invece di alternative tipicamente statiche?

Quindi, lavoro in .Net. Realizzo progetti open source in .Net. Uno dei miei maggiori problemi con esso non è necessario con .Net, ma con la comunità e le strutture circostanti. Sembra ovunque che gli schemi e le stringhe di nomi magici siano trattati come il modo migliore per fare tutto. Dichiarazione audace, ma guarda:

ASP.Net MVC:

Ciao itinerario mondiale:

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

Ciò significa che ASP.Net MVC cercherà in qualche modo HomeControllernel tuo codice. In qualche modo crearne una nuova e quindi chiamare Index apparentemente la funzione con un idparametro di qualche tipo. E poi ci sono altre cose come:

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

E poi ci sono cose simili anche con XAML. DataContextviene trattato come un oggetto e devi sperare e pregare che si risolva nel tipo che desideri. DependencyProperties deve utilizzare stringhe magiche e convenzioni di denominazione magica. E cose come questa:

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

Anche se si basa maggiormente sul casting e su vari supporti runtime magici.

Ad ogni modo, dico tutto ciò per finire qui: perché questo è così ben tollerato nel mondo .Net? Non stiamo usando linguaggi tipicamente statici per sapere quasi sempre che tipo di cose sono? Perché la riflessione e il tipo / metodo / proprietà / qualunque nome (come stringhe) preferisce così tanto rispetto a generici e delegati o persino alla generazione di codice?

Ci sono motivi ereditari che mi mancano per cui la sintassi del routing di ASP.Net si basa quasi esclusivamente sulla riflessione per risolvere effettivamente come gestire un percorso? Odio quando cambio il nome di un metodo o di una proprietà e improvvisamente le cose si rompono, ma non sembrano esserci riferimenti a quel metodo o proprietà e non ci sono ovviamente errori del compilatore. Perché l'apparente convenienza delle corde magiche era considerata "degna"?

So che ci sono anche alternative tipicamente statiche ad alcune cose, ma di solito prendono un sedile posteriore e sembrano non essere mai in tutorial o altro materiale per principianti.

In realtà c'è un respingimento nel mondo .NET contro queste stesse cose che hai citato. Nel primo esempio fornito, tuttavia, al motore di routing viene assegnata una convenzione per la mappatura del percorso predefinito. Il fatto stesso che i percorsi siano dinamici rende quasi impossibile utilizzare una configurazione statica.

Si menziona anche XAML / WPF, entrambi in fase di sviluppo molto prima che i generici fossero introdotti in .NET e che tornando a supportare i generici avrebbe ritardato ulteriormente un prodotto già molto recente (Longhorn / Vista).

Ci sono esempi all'interno del framework ASP.NET MVC dell'uso delle espressioni lambda al posto delle stringhe magiche e Entity Framework / LINQ lo porta ancora di più laddove il linguaggio e il framework forniscono supporto nativo per la composizione di query SQL su un grafico a oggetti statici (invece di costruire stringhe SQL magiche, ottieni la convalida del tempo di compilazione delle tue query).

Per altri esempi di configurazione statica, consultare la Structuremap e altri moderni contenitori per l'iniezione di dipendenze e altri framework che devono ispezionare il grafico degli oggetti in fase di esecuzione ma che consentono allo sviluppatore di fornire suggerimenti statici utilizzando espressioni lambda.

Quindi la risposta breve è che storicamente .NET non supportava l'attraversamento statico di un grafico a oggetti fino alla versione 3.5. Ora che ce l'abbiamo, molti sviluppatori lo preferiscono alle stringhe magiche e molti hanno spinto per un supporto ancora più profondo come un operatore SymbolOf che funziona in modo simile all'operatore TypeOf.