Perché il mondo .Net sembra abbracciare stringhe magiche invece di alternative tipizzate in modo statico?

46

Quindi, lavoro in .Net. Faccio progetti open source in .Net. Uno dei miei maggiori problemi con esso non è necessariyl con .Net, ma con la comunità e le strutture intorno ad esso. Sembra ovunque che schemi e stringhe di nomi magici vengano trattati come il modo migliore per fare tutto. Grassetto, ma guardalo:

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 HomeController nel codice. In qualche modo ne crea una nuova istanza, quindi chiama la funzione Index apparentemente con un parametro id 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. DataContext è trattato come un oggetto e devi sperare e pregare che si risolva nel tipo desiderato. DependencyProperties deve utilizzare stringhe magiche e convenzioni di denominazione magica. E cose del genere:

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

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

Ad ogni modo, dico tutto questo per finire qui: perché è così ben tollerato nel mondo .Net? Non stiamo usando linguaggi tipizzati staticamente per sapere quasi sempre qual è il tipo di cose? Perché la riflessione e il tipo / metodo / proprietà / quali nomi (come stringhe) preferiscono così tanto rispetto ai generici e ai delegati o persino alla generazione del codice?

Ci sono motivi ereditari che mi mancano perché la sintassi di 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 proprietà e improvvisamente le cose si rompono, ma non sembrano esserci riferimenti a quel metodo o proprietà e ovviamente non ci sono errori del compilatore. Perché l'apparente comodità delle stringhe magiche era considerata "ne vale la pena"?

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

    
posta Earlz 14.02.2013 - 19:33
fonte

1 risposta

30

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

Hai menzionato anche XAML / WPF, entrambi in fase di sviluppo ben prima che i generici venissero introdotti in .NET e tornando a supportare i generici avrebbero ritardato ulteriormente un prodotto già molto avanzato (Longhorn / Vista).

Nel framework ASP.NET MVC ci sono esempi di utilizzo di espressioni lambda al posto di stringhe magiche e Entity Framework / LINQ lo porta ancora oltre dove il linguaggio e il framework fornisce il supporto nativo per la composizione di query SQL su un grafico di oggetto statico ( invece di costruire stringhe SQL magiche, si ottiene la convalida del tempo di compilazione delle query).

Per altri esempi di configurazione statica, consulta structuremap e altri contenitori di iniezione di dipendenza moderni e altri framework che devono ispezionare il grafico degli oggetti in fase di esecuzione ma consentire allo sviluppatore di fornire suggerimenti in modo statico utilizzando espressioni lambda.

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

    
risposta data 14.02.2013 - 22:04
fonte

Leggi altre domande sui tag